08/08/2019 12:59, Jerin Jacob Kollanukkaran: > From: Ananyev, Konstantin <konstantin.anan...@intel.com> > > From: Jerin Jacob Kollanukkaran [mailto:jer...@marvell.com] > > > From: Ananyev, Konstantin <konstantin.anan...@intel.com> > > > > > > > From: Pavan Nikhilesh <pbhagavat...@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.