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.monja...@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