lkml.org 
[lkml]   [2019]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure
    Hi Igor,

    On Tue, Aug 13, 2019 at 04:18:40PM +0000, Igor Russkikh wrote:
    > On 13.08.2019 16:17, Andrew Lunn wrote:
    > > On Tue, Aug 13, 2019 at 10:58:17AM +0200, Antoine Tenart wrote:
    > >> I think this question is linked to the use of a MACsec virtual interface
    > >> when using h/w offloading. The starting point for me was that I wanted
    > >> to reuse the data structures and the API exposed to the userspace by the
    > >> s/w implementation of MACsec. I then had two choices: keeping the exact
    > >> same interface for the user (having a virtual MACsec interface), or
    > >> registering the MACsec genl ops onto the real net devices (and making
    > >> the s/w implementation a virtual net dev and a provider of the MACsec
    > >> "offloading" ops).
    > >>
    > >> The advantages of the first option were that nearly all the logic of the
    > >> s/w implementation could be kept and especially that it would be
    > >> transparent for the user to use both implementations of MACsec.
    > >
    > > We have always talked about offloading operations to the hardware,
    > > accelerating what the linux stack can do by making use of hardware
    > > accelerators. The basic user API should not change because of
    > > acceleration. Those are the general guidelines.
    > >
    > > It would however be interesting to get comments from those who did the
    > > software implementation and what they think of this architecture. I've
    > > no personal experience with MACSec, so it is hard for me to say if the
    > > current architecture makes sense when using accelerators.
    >
    > In terms of overall concepts, I'd add the following:
    >
    > 1) With current implementation it's impossible to install SW macsec engine onto
    > the device which supports HW offload. That could be a strong limitation in
    > cases when user sees HW macsec offload is broken or work differently, and he/she
    > wants to replace it with SW one.
    > MACSec is a complex feature, and it may happen something is missing in HW.
    > Trivial example is 256bit encryption, which is not always a musthave in HW
    > implementations.

    Agreed. I'm not sure it would be possible to have both used at the same
    time but there should be a way to switch between the two
    implementations. That is not supported for now, but I think that would
    be a good thing, and can probably come later on.

    > 2) I think, Antoine, its not totally true that otherwise the user macsec API
    > will be broken/changed. netlink api is the same, the only thing we may want to
    > add is an optional parameter to force selection of SW macsec engine.

    I meant that we can either have a virtual net device representing the
    MACsec feature and being the iface used to configure it, or we could
    have it only when s/w MACsec is used. That to me is part of the "API",
    or at least part of what's exposed to the user.

    > I'm also eager to hear from sw macsec users/devs on whats better here.

    I'd like more comments as well :)

    Thanks!
    Antoine

    --
    Antoine Ténart, Bootlin
    Embedded Linux and Kernel engineering
    https://bootlin.com

    \
     
     \ /
      Last update: 2019-08-14 10:32    [W:3.750 / U:0.736 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site