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 <ma...@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 <arybche...@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)