This series adds support for steering VxLAN flows using the ethtool NFC
interface, and implements it for hns3 devices.

Guangbin Huang (2):
  net: ethtool: add VxLAN to the NFC API
  net: hns3: support set/get VxLAN rule of rx flow director by ethtool

 .../hisilicon/hns3/hns3pf/hclge_main.c        | 272 +++++++++++++++++-
 .../hisilicon/hns3/hns3pf/hclge_main.h        |   2 +
 include/uapi/linux/ethtool.h                  |  48 ++++
 3 files changed, 319 insertions(+), 3 deletions(-)

-- 
2.33.0

On Wed, 17 Aug 2022 22:35:36 +0800 Guangbin Huang wrote:
> This series adds support for steering VxLAN flows using the ethtool NFC
> interface, and implements it for hns3 devices.

Why can't TC be used for this? Let's not duplicate the same
functionality in two places, TC flower can already match on 
tunnel headers.

On 2022/8/18 2:16, Jakub Kicinski wrote:
> On Wed, 17 Aug 2022 22:35:36 +0800 Guangbin Huang wrote:
>> This series adds support for steering VxLAN flows using the ethtool NFC
>> interface, and implements it for hns3 devices.
> 
> Why can't TC be used for this? Let's not duplicate the same
> functionality in two places, TC flower can already match on
> tunnel headers.
> .
> 
Hi Jakub,
1. I check the manual and implement of TC flower, it doesn't seems
    to support configuring flows steering to a specific queue.
2. Our hns3 driver has supported configuring some type of flows
    steering to a specific queue by ethtool -U command, many users
    have already use ethtool way.
3. In addition, if our driver supports TC flower to configure flows
    steering to a specific queue, can we allow user to simultaneously
    use TC flower and ethtool to configure flow rules? Could the rules
    configured by TC flower be queried by ethtool -u?
    If two ways can be existing, I think it is more complicated for
    driver to manage flow rules.

On Mon, 22 Aug 2022 22:46:14 +0800 huangguangbin (A) wrote:
> 1. I check the manual and implement of TC flower, it doesn't seems
>     to support configuring flows steering to a specific queue.

We got an answer from Sridhar on that one (thanks!)
I know it was discussed so it's a SMOC.

> 2. Our hns3 driver has supported configuring some type of flows
>     steering to a specific queue by ethtool -U command, many users
>     have already use ethtool way.
> 3. In addition, if our driver supports TC flower to configure flows
>     steering to a specific queue, can we allow user to simultaneously
>     use TC flower and ethtool to configure flow rules? Could the rules
>     configured by TC flower be queried by ethtool -u?
>     If two ways can be existing, I think it is more complicated for
>     driver to manage flow rules.

I understand your motivation and these are very valid points.
However, we have to draw the line somewhere. We have at least
three ways of configuring flow offloads (ethtool, nft, tc).
Supporting all of them is a lot of work for the drivers, leading
to a situation where there's no "standard Linux API" because each
vendor picks a slightly different approach :(
TC seems the most popular because of the OVS offload, so my preference
is to pick it over the other APIs.

on 2022/8/23 0:53, Jakub Kicinski wrote:
> On Mon, 22 Aug 2022 22:46:14 +0800 huangguangbin (A) wrote:
>
> I understand your motivation and these are very valid points.
> However, we have to draw the line somewhere. We have at least
> three ways of configuring flow offloads (ethtool, nft, tc).
> Supporting all of them is a lot of work for the drivers, leading
> to a situation where there's no "standard Linux API" because each
> vendor picks a slightly different approach :(
> TC seems the most popular because of the OVS offload, so my preference
> is to pick it over the other APIs.


Hi, Jakub,

I have recently taken over this job and used tc flow to configure flow steering to a specific queue.
Currently, the community already supports FLOW_ACTION_RX_QUEUE_MAPPING, so the previously discussed issue no longer exists.

However, we have encountered new problems:
1. First, the driver does not support FLOW_ACTION_REDIRECT, and the NIC is not a switching device.
     Therefore, I personally think that the driver does not need to implement switchdev.
2. However, the VF itself supports flow rules, and its capabilities are the same as those of the PF.
     The VF supports drop and select_queue, and the VF rules are configured through the PF.
3. However, it seems that tc flow does not have a proper parameter to specify the vf_id to tell the PF
     which VF to configure the rules for.

Therefore, we have encountered a problem in supporting tc flow for the VF.
A feasible idea is to use chain_index to indicate the vf_id.
However, this changes the original meaning of chain_index, which may cause confusion.
Or perhaps I missed some feature about vf in TC Flow?

I'd appreciate your insights on how to proceed.
Are there existing mechanisms or planned extensions to address VF-specific rule configuration?

Thanks,
Jijie Shao

On 2022/8/23 0:53, Jakub Kicinski wrote:
> On Mon, 22 Aug 2022 22:46:14 +0800 huangguangbin (A) wrote:
>> 1. I check the manual and implement of TC flower, it doesn't seems
>>      to support configuring flows steering to a specific queue.
> 
> We got an answer from Sridhar on that one (thanks!)
> I know it was discussed so it's a SMOC.
> 
>> 2. Our hns3 driver has supported configuring some type of flows
>>      steering to a specific queue by ethtool -U command, many users
>>      have already use ethtool way.
>> 3. In addition, if our driver supports TC flower to configure flows
>>      steering to a specific queue, can we allow user to simultaneously
>>      use TC flower and ethtool to configure flow rules? Could the rules
>>      configured by TC flower be queried by ethtool -u?
>>      If two ways can be existing, I think it is more complicated for
>>      driver to manage flow rules.
> 
> I understand your motivation and these are very valid points.
> However, we have to draw the line somewhere. We have at least
> three ways of configuring flow offloads (ethtool, nft, tc).
> Supporting all of them is a lot of work for the drivers, leading
> to a situation where there's no "standard Linux API" because each
> vendor picks a slightly different approach :(
> TC seems the most popular because of the OVS offload, so my preference
> is to pick it over the other APIs.
> .
> 
Ok.

On 8/22/2022 9:46 AM, huangguangbin (A) wrote:
>
>
> On 2022/8/18 2:16, Jakub Kicinski wrote:
>> On Wed, 17 Aug 2022 22:35:36 +0800 Guangbin Huang wrote:
>>> This series adds support for steering VxLAN flows using the ethtool NFC
>>> interface, and implements it for hns3 devices.
>>
>> Why can't TC be used for this? Let's not duplicate the same
>> functionality in two places, TC flower can already match on
>> tunnel headers.
>> .
>>
> Hi Jakub,
> 1. I check the manual and implement of TC flower, it doesn't seems
>    to support configuring flows steering to a specific queue.

Based on the discussion in this email thread
   https://lore.kernel.org/netdev/20220429171717.5b0b2a81@kernel.org/
Amritha will be submitting a patch series soon to enable redirecting to 
a RX qeueue
via  tc flower using skbedit queue_mapping action offload.

- Sridhar