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. What we might look at doing instead of trying to add support for other parts would be to explicitly limit this functionality to the i210 since if I am not mistaken this may be a feature only available in that hardware. Thanks. - Alex
