Re: [PATCH net] macsec: Abort MACSec Rx offload datapath when skb is not marked with MACSec metadata

[Rahul Rameshbabu <rrameshbabu@nvidia.com>]

On Wed, 15 Nov, 2023 16:19:27 +0100 Sabrina Dubroca <sd@queasysnail.net> wrote:
> 2023-11-06, 14:15:11 -0800, Rahul Rameshbabu wrote:
>> However, I believe that all macsec offload supporting devices run into
>> the following problem today (including mlx5 devices).
>
> If that's the case, we have to fix all of them.

I have an RFC patch series undergoing internal review for supporting
devices that advertise md_dst for handling non-MACsec multicast traffic
sent to the port. In the cover letter, I describe why I do not believe
the same case can be trivially handled for devices that do not support
setting md_dst since there is no way of knowing whether the traffic
received on the port was MACsec or not.

>
>> When I configure macsec offload on a device and then vlan on top of the
>> macsec interface, I become unable to send traffic through the underlying
>> device.
> [...]
>>   ping -I mlx5_1 1.1.1.2
>>   PING 1.1.1.2 (1.1.1.2) from 1.1.1.1 mlx5_1: 56(84) bytes of data.
>>   From 1.1.1.1 icmp_seq=1 Destination Host Unreachable
>>   ping: sendmsg: No route to host
>>   From 1.1.1.1 icmp_seq=2 Destination Host Unreachable
>>   From 1.1.1.1 icmp_seq=3 Destination Host Unreachable
>
> Which packet gets dropped and why? Where? I don't understand how the
> vlan makes a difference in a packet targeting the lower device.
>
>> I am thinking the solution is a combination of annotating which macsec
>> devices support md_dst and this patch.
>
> Yes, if we know that the offloading device sets md_dst on all its
> offloaded packets, we can just look up the rx_sc based on the sci and
> be done, or pass the packet directly to the real device if md_dst
> wasn't provided. No need to go through the MAC address matching at
> all.
>

This is exactly what the RFC patch series I am proposing looks like.

>> However, I am not sure this fix
>> would be helpful for devices that support macsec offload without
>> utilizing md_dst information (would still be problematic).
>
> Yeah, anything relying on md_dst is not going to help the rest of the
> drivers.

Right, I have an example in the cover letter that elaborates on why I do
not think it's possible to support this on devices that do not set
md_dst. I think the existing handling for multicast messages and
promiscuous mode in handle_not_macsec is the most appropriate for
drivers unable to set md_dst to indicate whether traffic received on the
port is MACsec traffic that will be handled by the NIC's offloading
functionality. Let me try to get that RFC out on the list soon for your
review.

--
Thanks,

Rahul Rameshbabu