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. Thanks & regards, Tiwei Bie
