netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: "Singhai, Anjali" <anjali.singhai@intel.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	Boris Pismenny <borisp@nvidia.com>,
	"gal@nvidia.com" <gal@nvidia.com>,
	"cratiu@nvidia.com" <cratiu@nvidia.com>,
	"rrameshbabu@nvidia.com" <rrameshbabu@nvidia.com>,
	"steffen.klassert@secunet.com" <steffen.klassert@secunet.com>,
	"tariqt@nvidia.com" <tariqt@nvidia.com>,
	"Samudrala, Sridhar" <sridhar.samudrala@intel.com>,
	"Acharya, Arun Kumar" <arun.kumar.acharya@intel.com>
Subject: Re: [RFC net-next 00/15] add basic PSP encryption for TCP connections
Date: Fri, 21 Jun 2024 17:30:43 -0700	[thread overview]
Message-ID: <20240621173043.4afac43f@kernel.org> (raw)
In-Reply-To: <CO1PR11MB49939F947A63E4A5F8C5246A93C82@CO1PR11MB4993.namprd11.prod.outlook.com>

On Thu, 20 Jun 2024 21:32:14 +0000 Singhai, Anjali wrote:
> > > 1. Why do we need  ndo_op set_config() at device level which is setting only one version, instead the description above the psp_dev struct which had a mask for enabled versions at a  device level is better and device lets the stack know at psp_dev create time what all versions it is capable of.  Later on, version is negotiated with the peer and set per session.
> > > Even the Mellanox driver does not implement this set_config ndo_op. 
> >  >  
> Can you or Kuba comment on this?

For now the only action the driver can perform is to disable PSP Rx
handling:

https://github.com/kuba-moo/linux/blob/psp/drivers/net/ethernet/mellanox/mlx5/core/en_accel/psp.c#L18

> > > 2. Where is the association_index/handle returned to the stack to be used with the packet on TX by the driver and device? ( if an SADB is in use on Tx side in the device), what we understand from Mellanox driver is, its not doing an SADB in TX in HW, but passing the key directly into the Tx descriptor? Is that right, but other devices may not support this and will have an SADB on TX and this allowed as per PSP protocol. Of course on RX there is no SADB for any device.
> > > In our device we have 2 options, 
> > >             1. Using SADB on TX and just passing SA_Index in the descriptor (trade off between performance and memory. 
> > >             As  passing key in descriptor makes for a much larger TX descriptor which will have perf penalty.)
> > >            2. Passing key in the descriptor.
> > >             For us we need both these options, so please allow for enhancements.
> > >  
> Can you or Kuba comment on this? This is critical, also in the fast path, skb needs to carry the SA_index/handle (like the tls case) instead of the key or both so that either method can be used by the device driver/device.

The ID should go into the driver state of the association, specify how
much space you need by setting this:
https://github.com/kuba-moo/linux/blob/psp/include/net/psp/types.h#L110C6-L110C19
Then you can access it via psp_assoc_drv_data()

AFAICT Willem answered all the other points.

  parent reply	other threads:[~2024-06-22  0:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-18 23:54 [RFC net-next 00/15] add basic PSP encryption for TCP connections Singhai, Anjali
2024-06-19  8:39 ` Willem de Bruijn
2024-06-19  8:47   ` Willem de Bruijn
2024-06-20 21:32   ` Singhai, Anjali
2024-06-21 12:05     ` Willem de Bruijn
2024-06-22  0:30     ` Jakub Kicinski [this message]
2024-06-25 22:05       ` Singhai, Anjali
2024-06-25 23:17         ` Jakub Kicinski
  -- strict thread matches above, loose matches on Subject: below --
2024-05-22 12:56 Paul Wouters
2024-05-22 13:03 ` Boris Pismenny
2024-05-28  9:42 ` Steffen Klassert
2024-05-28 13:49   ` Willem de Bruijn
2024-05-28 15:33     ` Paul Wouters
2024-05-28 18:09       ` Jakub Kicinski
2024-05-28 18:11       ` Willem de Bruijn
2024-05-31  6:09     ` Steffen Klassert
2024-05-31 14:46       ` Willem de Bruijn
2024-05-10  3:04 Jakub Kicinski
2024-05-29  9:16 ` Boris Pismenny
2024-05-29 18:50   ` Jakub Kicinski
2024-05-29 20:01     ` Boris Pismenny
2024-05-29 20:38       ` Jakub Kicinski

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=20240621173043.4afac43f@kernel.org \
    --to=kuba@kernel.org \
    --cc=anjali.singhai@intel.com \
    --cc=arun.kumar.acharya@intel.com \
    --cc=borisp@nvidia.com \
    --cc=cratiu@nvidia.com \
    --cc=gal@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rrameshbabu@nvidia.com \
    --cc=sridhar.samudrala@intel.com \
    --cc=steffen.klassert@secunet.com \
    --cc=tariqt@nvidia.com \
    --cc=willemdebruijn.kernel@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).