Cover Letter Detail
Show a cover letter.
GET /api/covers/896850/?format=api
{ "id": 896850, "url": "http://patchwork.ozlabs.org/api/covers/896850/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/cover/20180410174959.18757-1-vinicius.gomes@intel.com/", "project": { "id": 46, "url": "http://patchwork.ozlabs.org/api/projects/46/?format=api", "name": "Intel Wired Ethernet development", "link_name": "intel-wired-lan", "list_id": "intel-wired-lan.osuosl.org", "list_email": "intel-wired-lan@osuosl.org", "web_url": "", "scm_url": "", "webscm_url": "", "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<20180410174959.18757-1-vinicius.gomes@intel.com>", "list_archive_url": null, "date": "2018-04-10T17:49:49", "name": "[next-queue,v7,00/10] igb: offloading of receive filters", "submitter": { "id": 72272, "url": "http://patchwork.ozlabs.org/api/people/72272/?format=api", "name": "Vinicius Costa Gomes", "email": "vinicius.gomes@intel.com" }, "mbox": "http://patchwork.ozlabs.org/project/intel-wired-lan/cover/20180410174959.18757-1-vinicius.gomes@intel.com/mbox/", "series": [ { "id": 38278, "url": "http://patchwork.ozlabs.org/api/series/38278/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/list/?series=38278", "date": "2018-04-10T17:49:50", "name": "igb: offloading of receive filters", "version": 7, "mbox": "http://patchwork.ozlabs.org/series/38278/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/covers/896850/comments/", "headers": { "Return-Path": "<intel-wired-lan-bounces@osuosl.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Delivered-To": [ "patchwork-incoming@bilbo.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Authentication-Results": [ "ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.136; helo=silver.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=<UNKNOWN>)", "ozlabs.org;\n\tdmarc=none (p=none dis=none) header.from=intel.com" ], "Received": [ "from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 40LF7m5g0pz9s29\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 11 Apr 2018 03:50:28 +1000 (AEST)", "from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id 2ADFF25C6F;\n\tTue, 10 Apr 2018 17:50:27 +0000 (UTC)", "from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id hhoQO1u8pK-h; Tue, 10 Apr 2018 17:50:24 +0000 (UTC)", "from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby silver.osuosl.org (Postfix) with ESMTP id 2FF8E25B01;\n\tTue, 10 Apr 2018 17:50:24 +0000 (UTC)", "from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\tby ash.osuosl.org (Postfix) with ESMTP id CCFDF1CF105\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tTue, 10 Apr 2018 17:50:22 +0000 (UTC)", "from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id CA2D28511F\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tTue, 10 Apr 2018 17:50:22 +0000 (UTC)", "from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id Wt2TY7xy3JjI for <intel-wired-lan@lists.osuosl.org>;\n\tTue, 10 Apr 2018 17:50:22 +0000 (UTC)", "from mga03.intel.com (mga03.intel.com [134.134.136.65])\n\tby fraxinus.osuosl.org (Postfix) with ESMTPS id E818A84FCA\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tTue, 10 Apr 2018 17:50:21 +0000 (UTC)", "from orsmga005.jf.intel.com ([10.7.209.41])\n\tby orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t10 Apr 2018 10:50:21 -0700", "from kjnewhou-mobl1.amr.corp.intel.com (HELO localhost.localdomain)\n\t([10.254.183.149])\n\tby orsmga005.jf.intel.com with ESMTP; 10 Apr 2018 10:50:20 -0700" ], "X-Virus-Scanned": [ "amavisd-new at osuosl.org", "amavisd-new at osuosl.org" ], "X-Greylist": "domain auto-whitelisted by SQLgrey-1.7.6", "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.48,433,1517904000\"; d=\"scan'208\";a=\"215551485\"", "From": "Vinicius Costa Gomes <vinicius.gomes@intel.com>", "To": "intel-wired-lan@lists.osuosl.org", "Date": "Tue, 10 Apr 2018 10:49:49 -0700", "Message-Id": "<20180410174959.18757-1-vinicius.gomes@intel.com>", "X-Mailer": "git-send-email 2.17.0", "Subject": "[Intel-wired-lan] [next-queue PATCH v7 00/10] igb: offloading of\n\treceive filters", "X-BeenThere": "intel-wired-lan@osuosl.org", "X-Mailman-Version": "2.1.24", "Precedence": "list", "List-Id": "Intel Wired Ethernet Linux Kernel Driver Development\n\t<intel-wired-lan.osuosl.org>", "List-Unsubscribe": "<https://lists.osuosl.org/mailman/options/intel-wired-lan>, \n\t<mailto:intel-wired-lan-request@osuosl.org?subject=unsubscribe>", "List-Archive": "<http://lists.osuosl.org/pipermail/intel-wired-lan/>", "List-Post": "<mailto:intel-wired-lan@osuosl.org>", "List-Help": "<mailto:intel-wired-lan-request@osuosl.org?subject=help>", "List-Subscribe": "<https://lists.osuosl.org/mailman/listinfo/intel-wired-lan>, \n\t<mailto:intel-wired-lan-request@osuosl.org?subject=subscribe>", "Cc": "netdev@vger.kernel.org, jesus.sanchez-palencia@intel.com", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "7bit", "Errors-To": "intel-wired-lan-bounces@osuosl.org", "Sender": "\"Intel-wired-lan\" <intel-wired-lan-bounces@osuosl.org>" }, "content": "Hi,\n\nKnown issue:\n - It seems that the the QSEL bits in the RAH registers do not have\n any effect for source address (i.e. steering doesn't work for source\n address filters), everything is pointing to a hardware (or\n documentation) issue;\n\nChanges from v6:\n - Because the i210 doesn't support steering traffic per source\n address (only filtering works), an error is emitted when only an\n source address is specified in a classification rule;\n\nChanges from v5:\n - Filters can now be added for local MAC addresses, when removed,\n they return to their initial configuration (thanks for the testing\n Aaron);\n\nChanges from v4:\n - Added a new bit to the MAC address filters internal\n representation to mean that some filters are steering filters (i.e.\n they direct traffic to queues);\n - And, this is only supported in i210;\n\nChanges from v3:\n - Addressed review comments from Aaron F. Brown and\n Jakub Kicinski;\n\nChanges from v2:\n - Addressed review comments from Jakub Kicinski, mostly about coding\n style adjustments and more consistent error reporting;\n\nChanges from v1:\n - Addressed review comments from Alexander Duyck and Florian\n Fainelli;\n - Adding and removing cls_flower filters are now proposed in the same\n patch;\n - cls_flower filters are kept in a separated list from \"ethtool\"\n filters (so that section of the original cover letter is no longer\n valid);\n - The patch adding support for ethtool filters is now independent from\n the rest of the series;\n\nOriginal cover letter:\n\nThis series enables some ethtool and tc-flower filters to be offloaded\nto igb-based network controllers. This is useful when the system\nconfigurator want to steer kinds of traffic to a specific hardware\nqueue.\n\nThe first two commits are bug fixes.\n\nThe basis of this series is to export the internal API used to\nconfigure address filters, so they can be used by ethtool, and\nextending the functionality so an source address can be handled.\n\nThen, we enable the tc-flower offloading implementation to re-use the\nsame infrastructure as ethtool, and storing them in the per-adapter\n\"nfc\" (Network Filter Config?) list. But for consistency, for\ndestructive access they are separated, i.e. an filter added by\ntc-flower can only be removed by tc-flower, but ethtool can read them\nall.\n\nOnly support for VLAN Prio, Source and Destination MAC Address, and\nEthertype is enabled for now.\n\nOpen question:\n - igb is initialized with the number of traffic classes as 1, if we\n want to use multiple traffic classes we need to increase this value,\n the only way I could find is to use mqprio (for example). Should igb\n be initialized with, say, the number of queues as its \"num_tc\"?\n\n--\n\nVinicius Costa Gomes (10):\n igb: Fix not adding filter elements to the list\n igb: Fix queue selection on MAC filters on i210\n igb: Enable the hardware traffic class feature bit for igb models\n igb: Add support for MAC address filters specifying source addresses\n igb: Add support for enabling queue steering in filters\n igb: Allow filters to be added for the local MAC address\n igb: Enable nfc filters to specify MAC addresses\n igb: Add MAC address support for ethtool nftuple filters\n igb: Add the skeletons for tc-flower offloading\n igb: Add support for adding offloaded clsflower filters\n\n .../net/ethernet/intel/igb/e1000_defines.h | 2 +\n drivers/net/ethernet/intel/igb/igb.h | 13 +\n drivers/net/ethernet/intel/igb/igb_ethtool.c | 73 +++-\n drivers/net/ethernet/intel/igb/igb_main.c | 370 +++++++++++++++++-\n 4 files changed, 441 insertions(+), 17 deletions(-)\n\n--\n2.17.0" }