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

[Parav Pandit <parav@nvidia.com>]

> From: Heng Qi <hengqi@linux.alibaba.com>
> Sent: Monday, August 7, 2023 12:53 PM

> > >Once RSS context is done, at that point in future to enhance RFF.
> Hi, Parav.
> 
> We need the RSS context, which can be combined with 'ethtool -X .. equal'
> to achieve the purpose of traffic isolation, so please keep the RSS context. To
> allay your concerns that an RSS context might be blocking the work of n-tuples,
> I'll be issuing a spec this week (or next
> week) for virtio support for the RSS context. For n-tuple RFF context, we can
> support it after RFF, as a point to enhance RFF.
>
Ok. sounds good.
 
> > >[..]
> 
> > +9. The filter rule add/delete entries are usually short in size of few tens of
> > +   bytes, for example IPv6 + TCP tuple would be 36 bytes, and ops/sec rate is
> > +   high, hence supplying fields inside the queue descriptor is preferred for
> > +   up to a certain fixed size, say 56 bytes.
> 
> '56B' does not seem to be enough. For example, src mac + dst mac + src-ip6 +
> dst-ip6 + src-port + dst-port + user-define (packet byte offset pattern, length
> and mask) + flow id + rule priority + destination + action =
> 6 + 6 + 16 + 16 + 2 + 2 + 8 + 4 + 1 + 2 + 1 = 64 B, we also have structure alignment
> and quintuple mask, etc.
> 
Yes, 64B also need to add group id to it.
A practical finite limit would be fine, I took 56B example based on ipv4 case.
I think 96B at higher upper limit looks reasonable without considering mask.
As ARFS kind of use cases usually are exact match, hence mask is optional that doest need to be inline.

> > [..]
> > +5. The device should be able to expose if it support filter masks.
> > [..]
> > +7. Flow filter capabilities to query using a DMA interface:
> > +
> > +```
> > +struct flow_filter_capabilities {
> > +	u8 flow_groups;
> > +	u16 num_flow_filter_vqs;
> > +	u16 start_vq_index;
> > +	u32 max_flow_filters_per_group;
> > +	u32 max_flow_filters;
> > +	u64 supported_packet_field_mask_bmap[4];
> 
> I think the function here is that after the user sends the mask, the driver should
> do an 'AND' operation with the mask supported by the device first?
> Meanwhile, is 32B enough:) :
>   src-port + dst-port + src mac + dst mac + src-ip6 + dst-ip6 =
>     2 + 2 + 6 + 6 + 16 + 16 = 48B
> 
Oh I didnât document well.
The field supported_packet_field_mask_bmap is bitmap of well defined fields, one bit for each field.
Such as,
Bit_0 = dst_mac
Bit_1 = src_mac
Bit_2 = eth_type
Bit_3 = vlan_tag
Bit_4 = dst_ip 
And so on.

So yes, the actual content like src-port does not need to mask, but yes, 
when the filter rule arrives from ARFS or FC side, that metdata info coming in ethtool_rx_flow_spec to be masked.

It would make more sense to have a dedicated command for the bitmap for two reasons.
1. It doesn't get sandwiched in the future when new fields are added after the bitmap.
2. When bitmap needs to extend, it is not fragmented at two or more places.