OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [PATCH requirements 5/7] net-features: Add n-tuple receive flow filters requirements

> From: Heng Qi <hengqi@linux.alibaba.com>
> Sent: Tuesday, August 8, 2023 1:52 PM

> > Yes, but having single interface for two use cases enables the device
> implementation to not build driver interface specific infra.
> > Both can be handled by unified interface.
> I reconsidered the number of groups, we don't necessarily have only two groups
> for the time being (one is RFF, the other is ARFS). For example, the driver may
> maintain groups with different priorities for RFF itself (for example, according
> to the number of fields contained in ntuple, etc.), and the driver may also
> maintain different groups with the same priority for different flow types of
> ARFS, etc.

This is fine and covered with the interface.
Number of supported max groups is device capability that is exposed by the device.

How many groups to use and which priority assign to each is driver's decision.
So more than 2 groups is fine and supported by the requirements.

In Linux net device example, 2 groups seem enough, but spec is not limited to it.

When/if there is switch, it can also create a group and filter prioritize message before it reaches further nic processing.
But we can keep this aside for now to not complicate the discussion more.

So in nutshell, single interface is able to service the need of both ARFS and ethtool programming.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]