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

[Tiwei Bie]

On Wed, Jan 11, 2017 at 06:32:48PM +0100, Olivier MATZ wrote:
> 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.
> 

Sure! Thank you very much!

Best regards,
Tiwei Bie