Re: [dpdk-dev] [PATCH v3 0/6] Add MACsec offload support for ixgbe

[Tiwei Bie <tiwei.bie@intel.com>]

Hi Adrien,

On Tue, Dec 27, 2016 at 03:37:46PM +0100, Adrien Mazarguil wrote:
> Hi Tiwei,
> 
> On Tue, Dec 27, 2016 at 09:33:31AM +0800, Tiwei Bie wrote:
> > Hi Adrien,
> > 
> > On Mon, Dec 26, 2016 at 04:15:37PM +0100, Adrien Mazarguil wrote:
> > > Hi Tiwei,
> > > 
> > > On Sun, Dec 25, 2016 at 10:57:54PM +0800, Tiwei Bie wrote:
> > > > This patch set adds the MACsec offload support for ixgbe.
> > > > The testpmd is also updated to support MACsec cmds.
[...]
> > > - Why can't the MACsec API be defined globally, for instance won't i40e
> > >   implement it as well someday?
> > 
> > I think currently we prefer to implement some PMD features based on the
> > PMD-specific APIs at first to avoid the bloating of the ethdev APIs. And
> > when it proves to be generic (which means many people really need it and
> > care about it, and more drivers are really going to implement it), then
> > we make it as the global ethdev API.
> 
> Understandable, but then unless the global API remains exactly the same
> including the "rte_ixgbe_macsec" prefix (which I think won't happen),
> applications need to be rewritten, it's not convenient, and as a result may
> prevent adoption due to the following cycle:
> 
> - Applications wait for the API to evolve before using MACsec.
> - DPDK waits for applications to use the ixgbe MACsec API to improve it.
> 

Yeah, I also saw these problems. And I also don't think this is a
perfect way. But it seems that many of us prefer this way, so I just
choose to accept it.

> In the end, flags tied to a single PMD remain allocated in the global
> namespace while the API is kept in this temporary state forever.
> 
> I think doing the extra work to make it global from the start is worth the
> trouble. This step could perhaps be made easier if people agreed that
> struct eth_dev_ops (and friends) must be opaque to applications.
> 
[...]
> 
> > > Assuming these patches are kept as-is, I suggest we define a reserved space
> > > documented as such for PMD-specific flags wherever they are used.
> > > 
> > 
> > It sounds good to me. But it may involve many pieces of the lib, such
> > as the mbuf ol_flags, ethdev event type, ethdev offload capabilities,
> > and so on. So maybe it can be done as another work.
> 
> Right, that was just an idea from the top of my head, we could define
> reserved values only when they become necessary for a PMD as in this case,
> e.g. instead of defining PKT_TX_MACSEC, one would define PKT_TX_RESERVED_0
> which would be interpreted as MACSEC by ixgbe until this API is exposed
> globally.
> 
> Other PMDs could implement other unrelated PMD-specific APIs through
> RESERVED_0 in the meantime, so we preserve the precious space we have
> for global APIs (especially inside mbufs).
> 
> Thoughts?
> 

When a certain PMD implemented several different features based on
the PMD-specific API, and many of them need to define some flags in
mbuf or the like, it still needs to waste many bits (i.e. we'll need
to reserve many bits by that time). But any way, I love your idea!
It's much better than the current approach! I'll update my patch.
Thank you very much! ;-)

Best regards,
Tiwei Bie