netdev - RE: [Intel-wired-lan] [next-queue PATCH v4 6/8] igb: Add MAC address support for ethtool nftuple filters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <309B89C4C689E141A5FF6A0C5FB2118B8C80499F@ORSMSX101.amr.corp.intel.com>
Date:   Fri, 16 Mar 2018 18:14:37 +0000
From:   "Brown, Aaron F" <aaron.f.brown@...el.com>
To:     Alexander Duyck <alexander.duyck@...il.com>,
        "Gomes, Vinicius" <vinicius.gomes@...el.com>
CC:     "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Sanchez-Palencia, Jesus" <jesus.sanchez-palencia@...el.com>
Subject: RE: [Intel-wired-lan] [next-queue PATCH v4 6/8] igb: Add MAC
 address support for ethtool nftuple filters

> From: Alexander Duyck [mailto:alexander.duyck@...il.com]
> Sent: Friday, March 16, 2018 11:07 AM
> To: Gomes, Vinicius <vinicius.gomes@...el.com>
> Cc: Brown, Aaron F <aaron.f.brown@...el.com>; intel-wired-
> lan@...ts.osuosl.org; netdev@...r.kernel.org; Sanchez-Palencia, Jesus
> <jesus.sanchez-palencia@...el.com>
> Subject: Re: [Intel-wired-lan] [next-queue PATCH v4 6/8] igb: Add MAC
> address support for ethtool nftuple filters
> 
> On Fri, Mar 16, 2018 at 10:59 AM, Vinicius Costa Gomes
> <vinicius.gomes@...el.com> wrote:
> > Hi,
> >
> > Alexander Duyck <alexander.duyck@...il.com> writes:
> >
> >> On Tue, Mar 13, 2018 at 8:04 PM, Brown, Aaron F
> <aaron.f.brown@...el.com> wrote:
> >>>> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@...osl.org] On
> >>>> Behalf Of Vinicius Costa Gomes
> >>>> Sent: Wednesday, March 7, 2018 4:37 PM
> >>>> To: intel-wired-lan@...ts.osuosl.org
> >>>> Cc: netdev@...r.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> >>>> palencia@...el.com>
> >>>> Subject: [Intel-wired-lan] [next-queue PATCH v4 6/8] igb: Add MAC
> address
> >>>> support for ethtool nftuple filters
> >>>>
> >>>> This adds the capability of configuring the queue steering of arriving
> >>>> packets based on their source and destination MAC addresses.
> >>>>
> >>>> In practical terms this adds support for the following use cases,
> >>>> characterized by these examples:
> >>>>
> >>>> $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> >>>> (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> >>>> to the RX queue 0)
> >>>>
> >>>> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3
> >>>> (this will direct packets with source address "44:44:44:44:44:44" to
> >>>> the RX queue 3)
> >>>
> >>> This seems to work fine on i210, and the patch series allows me to set
> the rx filters on the i350, i354 and i211, but it is not directing the packets to
> the queue I request.
> >>>
> >>> With the exception of i210 the rx_queues number does not seem to be
> effected by setting the filter.  In the case of i211 the rx packets stay on
> rx_queue 0 with or without an ether src or dst filter.  The first example one
> seems to work at first since it's directing to queue 0, but changing the filter to
> "action 1" does not change the behavior.  With the i350 and i354 ports the
> packets are spread across the rx_queues with or without the filter set.
> >>
> >> Do any of the other parts actually support this functionality? I don't
> >> think they do.
> >
> > From what I can see, the only other part that supports queue steering (by
> MAC
> > addresses) is the 82575. But as I don't have any of those handy, making
> > it work only for the i210 seems more reasonable, to avoid getting into
> > this situation again.
> 
> That sounds good to me. What you might do is add a comment explaining
> that this is only supported on 82575 and i210 wherever you put the
> check that limits this. Then if we have time for the
> development/validation efforts, or someone in the community does they
> could take it upon themselves to enable and test it for 82575.
> 
> I have done similar things in the past. As long as it is clear that
> the reason why we limited it to i210 is mostly because of
> development/validation resources somebody else can come along and
> enable it if they have the resources and time to invest in doing so.

I do have a few of 82575 NICs in my lab and am perfectly willing to test them on whatever you come up with.  But I don't believe it is a common part at all so have no qualms with limiting it to i210.