lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 12 Jul 2022 06:50:52 +0000 From: Lior Nahmanson <liorna@...dia.com> To: Jakub Kicinski <kuba@...nel.org> CC: Paolo Abeni <pabeni@...hat.com>, "edumazet@...gle.com" <edumazet@...gle.com>, "davem@...emloft.net" <davem@...emloft.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Raed Salem <raeds@...dia.com>, Jiri Pirko <jiri@...dia.com>, Saeed Mahameed <saeedm@...dia.com>, Yossi Kuperman <yossiku@...dia.com> Subject: RE: [PATCH net-next v3 2/3] net/macsec: Add MACsec skb extension Rx Data path support > On Tue, 21 Jun 2022 12:39:23 +0000 Lior Nahmanson wrote: > > > Shooting from the hip a little bit, but macsec being a tightly bound > > > L2 upper maybe metadata dst is a workable solution for carrying the > > > sci and offload status between upper and lower? The range of values > > > should be well known and limited. > > > > Under the assumption that by skb_metadata you meant metadata_dst, > > Can you show me in my email where I said skb_metadata? > > > I think there are few reasons why i think is better to use skb extensions: > > > > 1. Unlike skb extension, the metadata_dst deallaction is handled directly by > the allocator. > > Since the sci and offloaded fields are shared between the MACsec > > driver and the offload driver (in our case mlx5 driver), for Rx, the > > metadata_dst allocation is done in the mlx5 driver, while the dealloction > should be done in the MACsec driver. > > This is undesired behavior. > > You allocate metadata skb once and then attach it to the skbs. > > > 2. medadata_dst is attached to the skb using skb_dst_set(), which set the > slow_gro bit. > > So there is no gain regarding slow_gro flow. > > > > 3. metadata_dst allocation require much more memory than needed for > > MACsec use case (mainly because struct dst_entry which seems redundant > for this case). i considered the usage of skb_metadata_dst, however i still think that skb_ext will fit more to MACsec offload implementation for the following reasons: 1. for Rx, each skb can have a different SCI and offloaded values which mandate allocation of metadata_dst for each skb which contradicts the desired usage for skb_metadata_dst where it's allocated once and a refcnt held whenever used. 2. skb_ext method is used in a similar IPsec offload implementation which in the future could make it easier to refactor this section to unify all crypto offloads skb_ext usage. apologize for the late respond.
Powered by blists - more mailing lists