Re: [PATCH net-next 0/2] net: ethtool add VxLAN to the NFC API

[Jijie Shao <shaojijie@huawei.com>]

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