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

Olivier MATZ olivier.matz at 6wind.com
Wed Jan 11 18:32:48 CET 2017

Hi Tiwei, Hi Thomas,

On Mon, 09 Jan 2017 12:26:53 +0100, Thomas Monjalon
<thomas.monjalon at 6wind.com> wrote:
> 2017-01-09 11:57, Tiwei Bie:
> > On Sun, Jan 08, 2017 at 08:39:55PM +0800, Ananyev, Konstantin
> > wrote:  
> > > > Well my first reply to this thread was asking why isn't the
> > > > whole API global from the start then?  
> > > 
> > > That's good question, and my preference would always be to have
> > > the API to configure this feature as generic one.
> > > I guess the main reason why it is not right now we don't reach an
> > > agreement how this API should look like: 
> > > http://dpdk.org/ml/archives/dev/2016-September/047810.html
> > > But I'll leave it to the author to provide the real reason
> > > here.   
> > 
> > Yes, currently this work just provided a thin layer over 82599's
> > hardware MACsec offload support to allow users configure 82599's
> > MACsec offload engine. The current API may be too specific and may
> > need a rework to be used with other NICs.  
> I think it is a really good approach to start such API privately in a
> driver. It will give us more time and experience to design a proper
> generic API.
> Regarding the mbuf flag, it looks straight-forward, and as it is IEEE
> standardized, I do not see any objection to add it now.
> However, I will wait for the approval of Olivier - as maintainer of
> mbuf.

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.


More information about the dev mailing list