On Wed, Jan 11, 2017 at 06:32:48PM +0100, Olivier MATZ wrote:
> Generally speaking, we have to be careful when introducing new mbuf
> flags, since we don't have so much of them (~25 remaining out of 64,
> which mean we may run out of them in 3-4 years).
>
> In this particular case, despite the flag is added for an ixgbe-specific
> API, when MACsec will be implemented on another PMD, the exact same
> flag would also be needed. That's the same for the ethdev capability
> flag. Moreover, as Thomas stated, it's a standardized protocol so it's
> legitimate to have it included in rte_mbuf.h.
>
> For me, having PMD-specific APIs for a new feature is not a problem,
> but I think we should try to have a generic API as soon as the feature
> is supported by several PMDs.
JFYI, here is how the virtio handle the feature bits. It basically
just divides it to two parts.
>From virtio 1.0 spec (2.2 Feature Bits):
Feature bits are allocated as follows:
- 0 to 23 Feature bits for the specific device type
- 24 to 32 Feature bits reserved for extensions to the queue and feature
negotiation mechanisms
- 33 and above Feature bits reserved for future extensions.
Note: For example, feature bit 0 for a network device (i.e. Device ID 1)
indicates that the device supports checksumming of packets.
--yliu
