Re: [dpdk-dev] [PATCH v5 3/8] ethdev: reserve capability flags for PMD-specific API

[Tiwei Bie <tiwei.bie@intel.com>]

On Thu, Jan 05, 2017 at 09:33:22AM +0100, Adrien Mazarguil wrote:
> On Thu, Jan 05, 2017 at 07:56:08AM +0800, Tiwei Bie wrote:
> > On Thu, Jan 05, 2017 at 01:44:18AM +0800, Ananyev, Konstantin wrote:
> > [...]
> > > > >
> > > > > I understand that.
> > > > > My question was: suppose user would like to create a bonded device over 2 NICs.
> > > > > One of them is ixgbe, while other would be some other type.
> > > > > In future get_dev_info() for each of them might return DEV_RX_OFFLOAD_RESERVED_0  bit as set.
> > > > > But it would mean completely different thing.
> > > > > How bonded device would know that to deal properly?
> > > > >
> > > > > Another example - user has 2 NICs of different type and would like to send the same packet on both of them simultaneously.
> > > > > As PKT_TX_RESERVED might mean different things for these devices, and user would like to use let say
> > > > > PKT_TX_IXGBE_MACSEC on one of them, he would need to do a copy of them, instead just increment a refcnt.
> > > > >
> > > > > Similar issues might arise at RX handling: user got a packet with PKT_RX_RESERVED_0 set.
> > > > > What does it really mean if there are different NIC types in the system?
> > > > > The only way to answer that question, as I can see,  is to keep track from what NIC that packet was received.
> > > > > Which I suppose, is not always convenient.
> > > > >
> > > > 
> > > > The main purpose is to put the PMD-specific APIs in a separate
> > > > namespace instead of mixing the PMD-specific APIs and global APIs
> > > > up, and also save the bits in mbuf.ol_flags.
> > > > 
> > > > There are other ways to achieve this goal, such as introducing
> > > > the PMD specific ol_flags in mbuf second cache line as you said.
> > > > I just thought defining some reserved bits seems to be the most
> > > > simple way which won't introduce many changes.
> > > > 
> > > > What's your suggestions? Should I just revert the changes and
> > > > define the generic flags directly?
> > > 
> > > Yes, that would be my preference.
> > > As I said above - spending extra bit in ol_flags  doesn't look like a big problem to me.
> > > In return there would be no need to consider how to handle all that confusing scenarios in future.
> > 
> > Okay. I'll update my patches. Thanks a lot for your comments.
> 
> Well, I do not agree with Konstantin (no one saw this coming eh?) and do not
> think you need to update your series again.
> 

Hi Adrien,

Thank you very much! :-)

Hi Thomas and Olivier,

I don't have strong opinions here, although I prefer to put
the PMD-specific APIs in a separate namespace. I'd like to
hear or follow your opinions since you are the maintainers
of ethdev and mbuf.

Best regards,
Tiwei Bie

> PMD-specific symbols have nothing to do in the global namespace in my
> opinion, they are not versioned and may evolve without notice. Neither
> applications nor the bonding PMD can rely on them. That's the trade-off.
> 
> Therefore until APIs are made global, the safe compromise is to define
> neutral, reserved symbols that any PMD can use to implement their own
> temporary APIs for testing purposes. These can be renamed later without
> changing their value as long as a single PMD uses them.
> 
> -- 
> Adrien Mazarguil
> 6WIND