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

On Mon, Aug 14, 2023 at 05:15:06AM +0000, Parav Pandit wrote:
> > 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.

Yes, that's what I want to stress too.

> In Linux net device example, 2 groups seem enough,

Sorry I didn't understand this, are you referring to a net device
documentation or a driver implementation?

> 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.

Yes, I noticed Xuan's thread, so this can be discussed in his thread.


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