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
