> From: Alexander Duyck [mailto:alexander.du...@gmail.com] > Sent: Friday, March 16, 2018 11:07 AM > To: Gomes, Vinicius <vinicius.go...@intel.com> > Cc: Brown, Aaron F <aaron.f.br...@intel.com>; intel-wired- > l...@lists.osuosl.org; netdev@vger.kernel.org; Sanchez-Palencia, Jesus > <jesus.sanchez-palen...@intel.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.go...@intel.com> wrote: > > Hi, > > > > Alexander Duyck <alexander.du...@gmail.com> writes: > > > >> On Tue, Mar 13, 2018 at 8:04 PM, Brown, Aaron F > <aaron.f.br...@intel.com> wrote: > >>>> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > >>>> Behalf Of Vinicius Costa Gomes > >>>> Sent: Wednesday, March 7, 2018 4:37 PM > >>>> To: intel-wired-...@lists.osuosl.org > >>>> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez- > >>>> palen...@intel.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.
