| Message ID | 20240730012212.775814-1-yoong.siang.song@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add Default Rx Queue Setting for igc driver | expand |
On Tue, 30 Jul 2024 09:22:12 +0800 Song Yoong Siang wrote: > This patch set introduces the support to configure default Rx queue during runtime. > A new sysfs attribute "default_rx_queue" has been added, allowing users to check > and modify the default Rx queue. Why the extra uAPI.. a wildcard rule directing traffic to the "default" queue should do.
On Tuesday, July 30, 2024 10:55 PM, Jakub Kicinski <kuba@kernel.org> wrote: >On Tue, 30 Jul 2024 09:22:12 +0800 Song Yoong Siang wrote: >> This patch set introduces the support to configure default Rx queue during >runtime. >> A new sysfs attribute "default_rx_queue" has been added, allowing users to >check >> and modify the default Rx queue. > >Why the extra uAPI.. a wildcard rule directing traffic to the "default" >queue should do. Hi Jakub Kicinski, Regarding your suggestion of implementing a "wildcard rule," are you suggesting the use of an ethtool command similar to the following? ethtool -U <iface name> flow-type ether action <default queue> I have a concern that users might be not aware that this nfc rule is having lowest priority, as the default queue would only take effect when no other filtering rules match. Do you see this as a potential issue? If not, I am willing to proceed with exploring the ethtool options you've mentioned. Thank you for your guidance. Regards Siang
On Wed, 31 Jul 2024 07:40:11 +0000 Song, Yoong Siang wrote: > Regarding your suggestion of implementing a "wildcard rule," > are you suggesting the use of an ethtool command similar to the following? > > ethtool -U <iface name> flow-type ether action <default queue> > > I have a concern that users might be not aware that this nfc rule is having lowest priority, > as the default queue would only take effect when no other filtering rules match. I believe that ethtool n-tuple rules are expected to be executed in order. User can use the 'loc' argument to place the rule at the end of the table. > Do you see this as a potential issue? If not, I am willing to proceed with > exploring the ethtool options you've mentioned.
On 7/31/2024 7:43 AM, Jakub Kicinski wrote: > On Wed, 31 Jul 2024 07:40:11 +0000 Song, Yoong Siang wrote: >> Regarding your suggestion of implementing a "wildcard rule," >> are you suggesting the use of an ethtool command similar to the following? >> >> ethtool -U <iface name> flow-type ether action <default queue> >> >> I have a concern that users might be not aware that this nfc rule is having lowest priority, >> as the default queue would only take effect when no other filtering rules match. > > I believe that ethtool n-tuple rules are expected to be executed in > order. User can use the 'loc' argument to place the rule at the end > of the table. > Yes. Some drivers lack support for ordered rules, but instead enforce that no rule can be added if it would cause such a violation. In this case, (I haven't dug into the actual patches or code), I suspect the driver will need to validate the location values when adding rules to ensure that all rules which don't use the default queue have higher priority than the wild card rule. The request to add a filter should reject the rule in the case where a default queue rule was added with a higher priority location. >> Do you see this as a potential issue? If not, I am willing to proceed with >> exploring the ethtool options you've mentioned.
On Wed, 31 Jul 2024 09:41:16 -0700 Jacob Keller wrote: > In this case, (I haven't dug into the actual patches or code), I suspect > the driver will need to validate the location values when adding rules > to ensure that all rules which don't use the default queue have higher > priority than the wild card rule. The request to add a filter should > reject the rule in the case where a default queue rule was added with a > higher priority location. Maybe I shouldn't say it aloud but picking a "known" location for such a wildcard rule wouldn't be the worst thing. Obviously better if the driver just understand ordering!
On Thursday, August 1, 2024 7:53 AM, Jakub Kicinski <kuba@kernel.org> wrote: >On Wed, 31 Jul 2024 09:41:16 -0700 Jacob Keller wrote: >> In this case, (I haven't dug into the actual patches or code), I suspect >> the driver will need to validate the location values when adding rules >> to ensure that all rules which don't use the default queue have higher >> priority than the wild card rule. The request to add a filter should >> reject the rule in the case where a default queue rule was added with a >> higher priority location. > >Maybe I shouldn't say it aloud but picking a "known" location for such >a wildcard rule wouldn't be the worst thing. Obviously better if the >driver just understand ordering! Thanks Jakub Kicinski and Jacob Keller for the suggestions. I believe that it is a good idea to validate and ensure that the default queue rule is located at the lowest priority location (loc 63). I will go for this direction on my v2 submission.
This patch set introduces the support to configure default Rx queue during runtime. A new sysfs attribute "default_rx_queue" has been added, allowing users to check and modify the default Rx queue. This patch set is tested on two back-to-back connected i226 on Intel ADL-S systems. Test Steps and expected results: 1. Check default_rx_queue index: @DUT: $ cat /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/default_rx_queue 0 2. Check statistic of Rx packets: @DUT: $ ethtool -S enp2s0 | grep rx.*packets rx_packets: 0 rx_queue_0_packets: 0 rx_queue_1_packets: 0 rx_queue_2_packets: 0 rx_queue_3_packets: 0 3. Send 10 ARP packets: @LinkPartner: $ arping -c 10 -I enp170s0 169.254.1.10 ARPING 169.254.1.10 from 169.254.1.2 enp170s0 Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.725ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.649ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.577ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.611ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.706ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.644ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.648ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.601ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.628ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.641ms Sent 10 probes (1 broadcast(s)) Received 10 response(s) 4. Check statistic of Rx packets to make sure packets is received by default queue (RxQ0): @DUT: $ ethtool -S enp2s0 | grep rx.*packets rx_packets: 10 rx_queue_0_packets: 10 rx_queue_1_packets: 0 rx_queue_2_packets: 0 rx_queue_3_packets: 0 5. Change default_rx_queue index to Queue 3: @DUT: $ echo 3 | sudo tee /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/default_rx_queue 3 @DUT: $ cat /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/default_rx_queue 3 6. Send 10 ARP packets: @LinkPartner: $ arping -c 10 -I enp170s0 169.254.1.10 ARPING 169.254.1.10 from 169.254.1.2 enp170s0 Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.653ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.652ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.653ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.649ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.600ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.698ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.694ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.678ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.609ms Unicast reply from 169.254.1.10 [00:A0:C9:00:00:00] 0.634ms Sent 10 probes (1 broadcast(s)) Received 10 response(s) 7. Check statistic of Rx packets to make sure packets is received by new default queue (RxQ3): @DUT: $ ethtool -S enp2s0 | grep rx.*packets rx_packets: 20 rx_queue_0_packets: 10 rx_queue_1_packets: 0 rx_queue_2_packets: 0 rx_queue_3_packets: 10 Blanco Alcaine Hector (3): igc: Add documentation igc: Add default Rx queue configuration via sysfs igc: Add default Rx Queue into documentation .../device_drivers/ethernet/index.rst | 1 + .../device_drivers/ethernet/intel/igc.rst | 103 ++++++++++++ drivers/net/ethernet/intel/igc/Makefile | 3 +- drivers/net/ethernet/intel/igc/igc_main.c | 6 + drivers/net/ethernet/intel/igc/igc_regs.h | 6 + drivers/net/ethernet/intel/igc/igc_sysfs.c | 156 ++++++++++++++++++ drivers/net/ethernet/intel/igc/igc_sysfs.h | 10 ++ 7 files changed, 284 insertions(+), 1 deletion(-) create mode 100644 Documentation/networking/device_drivers/ethernet/intel/igc.rst create mode 100644 drivers/net/ethernet/intel/igc/igc_sysfs.c create mode 100644 drivers/net/ethernet/intel/igc/igc_sysfs.h