lkml.org 
[lkml]   [2023]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC net-next v2 5/5] net: phy: nxp-c45-tja11xx: implement mdo_insert_tx_tag
    2023-08-28, 16:46:02 +0300, Radu Pirea (OSS) wrote:
    >
    >
    > On 28.08.2023 13:17, Sabrina Dubroca wrote:
    > > 2023-08-24, 12:16:15 +0300, Radu Pirea (NXP OSS) wrote:
    > > > Implement mdo_insert_tx_tag to insert the TLV header in the ethernet
    > > > frame.
    > > >
    > > > If extscs parameter is set to 1, then the TLV header will contain the
    > > > TX SC that will be used to encrypt the frame, otherwise the TX SC will
    > > > be selected using the MAC source address.
    > >
    > > In which case would a user choose not to use the SCI? Using the MAC
    > > address is probably fine in basic setups, but having to fiddle with a
    > > module parameter (so unloading and reloading the module, which means
    > > losing network connectivity) to make things work when the setup
    > > evolves is really not convenient.
    > >
    > > Is there a drawback to always using the SCI?
    > >
    >
    > I see your concern. If the PHY driver is reloaded, then the offloaded MACsec
    > configuration will vanish from the hardware. Actually, just a call to
    > phy_disconnect is enough to break an offloaded MACsec iface and can be
    > achieved by:
    > ip link set eth0 down && ip link set eth0 up

    And it's not restored when the link goes back up? That's inconvenient :/
    Do we end up with inconsistent state? ie driver and core believe
    everything is still offloaded, but HW lost all state? do we leak
    some resources allocated by the driver?

    We could add a flush/restore in macsec_notify when the lower device
    goes down/up, maybe limited to devices that request this (I don't know
    if all devices would need it, or maybe all devices offloading to the
    PHY but not to the MAC).

    And what happens in this case?
    ip link add link eth0 type macsec offload phy
    ip link set eth0 down
    ip macsec add macsec0 rx sci ...
    ip macsec add macsec0 tx sa 0 ...
    # etc
    ip link set eth0 up

    Will offload work with the current code?

    > The only drawback is related to the PTP frames encryption. Due to hardware
    > limitations, PHY timestamping + MACsec will not work if the custom header is
    > inserted. The only way to get this work is by using the MAC SA selection and
    > running PTP on the real netdev.

    Could you add some documentation explaining that? Users need this
    information to make the right choice for their use case. Maybe
    directly in the description of the module parameter, something like:
    "Select the TX SC using TLV header information. PTP frames encryption
    cannot work when this feature is enabled."

    If it's in the module parameter I guess it can't be too
    verbose. Otherwise I don't know where else to put it.

    And the parameter's name and/or description should probably include
    macsec/MACsec if it's visible at the level of the whole module (ie if
    macsec support isn't a separate module), just to give context at to
    what the TXSC is (and what the encryption for the PTP frames refers
    to).

    --
    Sabrina

    \
     
     \ /
      Last update: 2023-08-30 21:16    [W:3.539 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site