[dpdk-dev] [PATCH 2/2] doc: announce new mbuf field for LRO

[Thomas Monjalon]

06/08/2019 20:17, Andrew Rybchenko:
> On 8/6/19 5:56 PM, Matan Azrad wrote:
> > The API breakage is because the ``tso_segsz`` field was documented for
> > LRO.
> >
> > The ``tso_segsz`` field in mbuf indicates the size of each segment in
> > the LRO packet in Rx path and should be provided by the LRO packet
> > port.
> >
> > While the generic LRO packet may aggregate different segments sizes in
> > one packet, it is impossible to expose this information for each segment
> > by one field and it doesn't make sense to expose all the segments sizes
> > in the mbuf.
> >
> > A new field may be added as union with the above field to expose the
> > number of segments aggregated in the LRO packet.
> >
> > Signed-off-by: Matan Azrad <matan at mellanox.com>
> > ---
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > +* mbuf: Remove ``tso_segsz`` mbuf field providing for LRO support. Use union
> > +  block for the field memory to be shared with a new field ``lro_segs_n``
> > +  indicates the number of segments aggregated in the LRO packet.
> 
> I think that the number of segments is more logical in the case of LRO.
> The question (already asked by Konstantin) is why it is needed at all
> (statistics?). If so, it still makes sense.
> 
> Segment size is misleading here, since not all segments
> could be the same size. So,
> 
> Acked-by: Andrew Rybchenko <arybchenko at solarflare.com>
> 
> As far as I can see bnxt and qede do not fill it in.
> mlx5 and vmxnet3 have the number of segments (vmxnet3 has segment
> size sometimes and sometimes use a function to guess the value).
> So both will win from the change.
> It looks like virtio does not have number of segments. CC Maxime to
> comment.

I support improving the API for LRO.
Unfortunately, the consensus is not strong enough at the moment.
Anyway we should avoid any API breakage in 19.11,
so I suggest to do only non-breaking additions in 19.11 if possible:
	- fill a new unioned field for LRO segments number
	- not set PKT_RX_LRO (which is still related to tso_segsz)