[PATCH iwl-next,v1 0/3] Add Default Rx Queue Setting for igc driver

[PATCH iwl-next,v1 0/3] Add Default Rx Queue Setting for igc driver

[Song Yoong Siang]

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

-- 
2.34.1

Re: [PATCH iwl-next,v1 0/3] Add Default Rx Queue Setting for igc driver

[Jakub Kicinski]

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.

RE: [PATCH iwl-next,v1 0/3] Add Default Rx Queue Setting for igc driver

[Song, Yoong Siang]

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

Re: [PATCH iwl-next,v1 0/3] Add Default Rx Queue Setting for igc driver

[Jakub Kicinski]

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.

Re: [Intel-wired-lan] [PATCH iwl-next, v1 0/3] Add Default Rx Queue Setting for igc driver

[Jacob Keller]

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.

Re: [Intel-wired-lan] [PATCH iwl-next, v1 0/3] Add Default Rx Queue Setting for igc driver

[Jakub Kicinski]

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!

RE: [Intel-wired-lan] [PATCH iwl-next, v1 0/3] Add Default Rx Queue Setting for igc driver

[Song, Yoong Siang]

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.