Re: [dpdk-dev] [patch v3] doc: announce API change in ethdev offload flags

[Thomas Monjalon <thomas@monjalon.net>]

08/08/2019 12:59, Jerin Jacob Kollanukkaran:
> From: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > From: Jerin Jacob Kollanukkaran [mailto:jerinj@marvell.com]
> > > From: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > > > > > From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> > > > > > One question about DEV_RX_OFFLOAD_PTYPE:
> > > > > > Does it mean that new ol_flags value (PKT_RX_PTYPE) will be
> > > > > > introduced to indicate that mbuf.packet_type value is set?
> > > > > > Or PMD will have to set  mbuf.packet_type to zero, when
> > > > > > DEV_RX_OFFLOAD_PTYPE was not enabled by user?
> > > > >
> > > > > I was thinking when DEV_RX_OFFLOAD_PTYPE is set
> > > > > - mbuf.packet_type will be valid and mbuf.packet_type will have
> > > > > parsed
> > > > packet type.
> > > > > If not set
> > > > > - mbuf.packet_type can be anything application should not use
> > > > mbuf.packet_type field.
> > > >
> > > > But in that case, we do need a new value for ol_flags, PKT_RX_PTYPE
> > > > or so, right?
> > >
> > > Since application has two knobs rte_eth_dev_get_supported_ptypes() and
> > > DEV_RX_OFFLOAD_PTYPE. We may not need to new ol_flags for this
> > change. Right?
> > > i.e if application sets the DEV_RX_OFFLOAD_PTYPE, The application will
> > > get the parsed ptypes by the driver(=
> > rte_eth_dev_get_supported_ptypes()).
> > > So there is no scope ambiguity. Right?
> > 
> > I still think there is:
> > Imagine user has 2 eth devices, one does support DEV_RX_OFFLOAD_PTYPE,
> > second doesn't.  Now he has a mix of packets from both devices, that you
> > want t process.
> > How would he figure out for which of them ptype values are valid, and for
> > each are not?
> > Trace back from what port he has received them?
> > Not very convenient, and not always possible.
> 
> I thought so. But in that case, application can always set DEV_RX_OFFLOAD_PTYPE
> Flags for all the ethdev ports. Right? Rather having any complicated ol_flags
> or port based parsing. If limit the _contract_ to following, we are good. Right?
> # when DEV_RX_OFFLOAD_PTYPE is set, mbuf.packet_type will be valid
> and mbuf.packet_type will have parsed packet type
> 
> or the negative offload(This contract is pretty clear, I don't think any ambiguity at all)
> # when DEV_RX_OFFLOAD_NO_PTYPE(something similar) is set,
> mbuf.packet_type will be invalid.

Just a note here: I am clearly against negative flags.
We recently cleaned up the flags to all be positive.