All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Cc: netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	"David S. Miller" <davem@davemloft.net>,
	Saeed Mahameed <saeed@kernel.org>
Subject: Re: [PATCH net] macsec: Abort MACSec Rx offload datapath when skb is not marked with MACSec metadata
Date: Wed, 15 Nov 2023 16:19:27 +0100	[thread overview]
Message-ID: <ZVThf1Z-hExKlDE2@hog> (raw)
In-Reply-To: <87r0l25y1c.fsf@nvidia.com>

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.

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

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

-- 
Sabrina


  reply	other threads:[~2023-11-15 15:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-01 20:02 [PATCH net] macsec: Abort MACSec Rx offload datapath when skb is not marked with MACSec metadata Rahul Rameshbabu
2023-11-01 22:31 ` Sabrina Dubroca
2023-11-06 22:15   ` Rahul Rameshbabu
2023-11-15 15:19     ` Sabrina Dubroca [this message]
2023-11-15 16:21       ` Rahul Rameshbabu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZVThf1Z-hExKlDE2@hog \
    --to=sd@queasysnail.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rrameshbabu@nvidia.com \
    --cc=saeed@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.