All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Feng Wang <wangfe@google.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>,
	netdev@vger.kernel.org, herbert@gondor.apana.org.au,
	davem@davemloft.net
Subject: Re: [PATCH] [PATCH ipsec] xfrm: Store ipsec interface index
Date: Wed, 3 Apr 2024 09:45:07 +0300	[thread overview]
Message-ID: <20240403064507.GR11187@unreal> (raw)
In-Reply-To: <CADsK2K8WvGmUdno5X=_ebNF1mzP9=kd1=ve31Tb5hSk+q4VTkg@mail.gmail.com>

On Tue, Apr 02, 2024 at 02:10:16PM -0700, Feng Wang wrote:
> The xfrm interface ID is the index of the ipsec device, for example,
> ipsec11, ipsec12.  One ipsec application(VPN) might create an ipsec11
> interface and send the data through this interface.
> Another application(Wifi calling) might create an ipsec12 interface and
> send its data through ipsec12.  Both packets are routed through the kernel
> to the one device driver(wifi).  When the device driver receives the
> packet, it needs to find the correct application parameters to encrypt the
> packet.  So if the skb_iif is marked by the kernel with ipsec11 or
> ipsec12,  device driver can use this information to find the corresponding
> parameter.  I hope I explain my user case clearly.  If there is any
> misunderstanding, please let me know.  I try my best to make it clear.

Like I said before, please send the code which uses this feature. Right
now, packet offload doesn't need this feature.

Thanks

> 
> Thanks Leon.
> Feng
> 
> 
> On Tue, Apr 2, 2024 at 12:51 AM Leon Romanovsky <leon@kernel.org> wrote:
> 
> > On Mon, Apr 01, 2024 at 11:09:41AM -0700, Feng Wang wrote:
> > > Thanks Leon for answering my question.  In the above example, if we can
> > > pass the xfrm interface id to the HW, then HW can distinguish them based
> > on
> > > it. That's what my patch is trying to do.
> >
> > From partial grep, it looks like "xfrm interface id" is actually netdevice
> > index. If this is the case, HW doesn't need to know about it, because
> > packet offload is performed by specific device and skb_iif will be equal
> > to that index anyway.
> >
> > > Would you please take this into consideration? If needed, I can improve
> > my
> > > patch.
> >
> > As a standalone patch, it is not correct. If you have a real use case,
> > please send together with code which uses it.
> >
> > Thanks
> >
> > >
> > > Thanks,
> > >
> > > Feng
> > >
> > >
> > >
> > >
> > > On Mon, Apr 1, 2024 at 7:27 AM Leon Romanovsky <leon@kernel.org> wrote:
> > >
> > > > On Fri, Mar 22, 2024 at 12:14:44PM -0700, Feng Wang wrote:
> > > > > Hi Leon and Steffen,
> > > > >
> > > > > Thanks for providing me with the information. I went through the
> > offload
> > > > > driver code but I didn't find any solution for my case.  Is there any
> > > > > existing solution available?  For example, there are 2 IPSec sessions
> > > > with
> > > > > the same xfrm_selector results, when trying to encrypt the packet,
> > how to
> > > > > find out which session this packet belongs to?
> > > >
> > > > HW catches packets based on match criteria of source and destination.
> > If
> > > > source, destination and other match criteria are the same for different
> > > > sessions, then from HW perspective, it is the same session.
> > > >
> > > > Thanks
> > > >
> >

  parent reply	other threads:[~2024-04-03  6:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-18 23:13 [PATCH] [PATCH ipsec] xfrm: Store ipsec interface index Feng Wang
2024-03-19  8:42 ` Leon Romanovsky
     [not found]   ` <CADsK2K_65Wytnr5y+5Biw=ebtb-+hO=K7hxhSNJd6X+q9nAieg@mail.gmail.com>
2024-03-20  4:33     ` Steffen Klassert
     [not found]       ` <CADsK2K-WFG2+2NQ08xBq89ty-G-xcoV517Eq5D7kNePcT4z0MQ@mail.gmail.com>
2024-03-21  9:32         ` Leon Romanovsky
     [not found]           ` <CADsK2K8=B=Yv4i6rzNdbuc-C6yc-pw6RSuRvKbsL2qYjsO9seg@mail.gmail.com>
2024-04-01 14:27             ` Leon Romanovsky
     [not found]               ` <CADsK2K-VLdiuxeP82bmuGvmU6z848mLpk+JBYdhXppOq0B76VA@mail.gmail.com>
2024-04-02  7:51                 ` Leon Romanovsky
     [not found]                   ` <CADsK2K8WvGmUdno5X=_ebNF1mzP9=kd1=ve31Tb5hSk+q4VTkg@mail.gmail.com>
2024-04-03  6:45                     ` Leon Romanovsky [this message]
2024-04-05 14:19                       ` Antony Antony

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=20240403064507.GR11187@unreal \
    --to=leon@kernel.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    --cc=wangfe@google.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 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.