DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Iremonger, Bernard" <bernard.iremonger@intel.com>
To: "Pathak, Pravin" <pravin.pathak@intel.com>,
	Anoob Joseph <anoobj@marvell.com>,
	satyavalli rama <satyavalli.rama@gmail.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-dev] [EXT] Re:  Ipsec-secgw packet processing
Date: Tue, 1 Sep 2020 11:07:25 +0000	[thread overview]
Message-ID: <DM6PR11MB253793F0C88379A0A794E5BDEF2E0@DM6PR11MB2537.namprd11.prod.outlook.com> (raw)
In-Reply-To: <BY5PR11MB41845BA02EED917C7EE873F3F4510@BY5PR11MB4184.namprd11.prod.outlook.com>

Hi Satya,

Inline ipsec is only supported by the ixgbe NIC, it is not supported by the i40e or e1000 NIC's.

Regards,

Bernard.

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Pathak, Pravin
> Sent: Monday, August 31, 2020 1:47 PM
> To: Anoob Joseph <anoobj@marvell.com>; satyavalli rama
> <satyavalli.rama@gmail.com>
> Cc: dev@dpdk.org; users@dpdk.org
> Subject: Re: [dpdk-dev] [EXT] Re: Ipsec-secgw packet processing
> 
> HI Satya -
> 
> Do you mean packets are not at all seen at the output OR packets are seen
> but data is not encrypted with just ESP headers added?
> This is what I see with Cypto NULL device and I think is expected behavior of
> NULL device.
> 
> Pravin
> 
> -----Original Message-----
> From: users <users-bounces@dpdk.org> On Behalf Of Anoob Joseph
> Sent: Monday, August 31, 2020 1:17 AM
> To: satyavalli rama <satyavalli.rama@gmail.com>
> Cc: dev@dpdk.org; users@dpdk.org
> Subject: Re: [dpdk-users] [EXT] Re: [dpdk-dev] Ipsec-secgw packet
> processing
> 
> Hi Satya,
> 
> What you are attempting is lookaside crypto offload. So in that case the
> mbuf->ol_flags fields won’t be used. Also, I’m not sure what all algos are
> available in ‘crypto_null’. In lookaside crypto offload model, packets are
> received in ipsec-secgw and lookup happens in ipsec-secgw. The packets
> would be then submitted to cryptodev for crypto processing. The cryptodev
> would be able to process the packet only if the algos specified are supported
> by it. IPsec processing also would be done in the application (ie, ipsec-
> secgw). Once all this done, it is submitted to ethdev for Tx. You can check the
> code and you will be able to figure out what I have described above.
> 
> Please do check ipsec-secgw documentation, if you haven’t done it already.
> 
> Thanks,
> Anoob
> 
> From: satyavalli rama <satyavalli.rama@gmail.com>
> Sent: Wednesday, August 26, 2020 4:54 PM
> To: Anoob Joseph <anoobj@marvell.com>
> Cc: dev@dpdk.org; users@dpdk.org
> Subject: [EXT] Re: [dpdk-dev] Ipsec-secgw packet processing
> 
> External Email
> ________________________________
> Hi Anoob,
> Do you need any more info.. Kindly help us.. We are totally stuck..
> Thanks
> 
> On Wed, 19 Aug, 2020, 4:38 pm satyavalli rama,
> <satyavalli.rama@gmail.com<mailto:satyavalli.rama@gmail.com>> wrote:
> Hi Anoob
> 
> We are using the following hardware details,
> HOST: x722 (i40e) intel.
> VM: e1000 (82540) intel.
> 
> We have launched Virtual machine on host , and executing ipsec-secgw
> application on VM.
> 
> Please find below the CLI and configuration for TRANSPORT MODE.
> 
> CLI:
> 
> ./build/ipsec-secgw -l 0 -n 4 --socket-mem 1024,0 --vdev "crypto_null" -- -p
> 0x3 -P -u 0x1 --config="(0,0,0),(1,0,0)" -f ep0.cfg
> 
> #TRANSPORT:
> 
> #SP IPv4 rules
> sp ipv4 out esp protect 10 pri 1 dst
> 192.168.122.0/24<https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__192.168.122.0_24&d=DwMFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=jPfB8
> rwwviRSxyLWs2n6B-
> WYLn1v9SyTMrT5EQqh2TU&m=UljpWEF8dI3bZcYKgM0AqP1ViNQsN-
> w4rZ1ZvTPc9Fw&s=UR36mFZdcNaE_w6k-
> jBS_XvmgSgAQzga2yAHh2jrIl4&e=> sport 0:65535 dport 0:65535
> 
> #SA rules
> sa out 10 cipher_algo aes-128-cbc cipher_key
> a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:\
> a1:a1:a1:a1:a1 auth_algo sha1-hmac auth_key
> a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:\
> a1:a1:a1:a1:a1:a1:a1:a1:a1 mode transport
> 
> #Routing rules
> rt ipv4 dst
> 192.168.122.0/24<https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__192.168.122.0_24&d=DwMFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=jPfB8
> rwwviRSxyLWs2n6B-
> WYLn1v9SyTMrT5EQqh2TU&m=UljpWEF8dI3bZcYKgM0AqP1ViNQsN-
> w4rZ1ZvTPc9Fw&s=UR36mFZdcNaE_w6k-
> jBS_XvmgSgAQzga2yAHh2jrIl4&e=> port 1
> 
> 
> Please find below the CLI and configuration for TUNNEL MODE.
> 
> CLI:
> 
> ./build/ipsec-secgw -l 0 -n 4 --socket-mem 1024,0 --vdev "crypto_null" -- -p
> 0x3 -P -u 0x1 --config="(0,0,0),(1,0,0)" -f ep0.cfg
> 
> #TUNNEL End Point-0:
> 
> #SP IPv4 rules
> sp ipv4 out esp protect 5 pri 1 dst
> 192.168.122.0/24<https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__192.168.122.0_24&d=DwMFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=jPfB8
> rwwviRSxyLWs2n6B-
> WYLn1v9SyTMrT5EQqh2TU&m=UljpWEF8dI3bZcYKgM0AqP1ViNQsN-
> w4rZ1ZvTPc9Fw&s=UR36mFZdcNaE_w6k-
> jBS_XvmgSgAQzga2yAHh2jrIl4&e=> sport 0:65535 dport 0:65535
> 
> #SA rules
> sa out 5 cipher_algo aes-128-cbc cipher_key 0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 \
> auth_algo sha1-hmac auth_key 0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 \ mode
> ipv4-tunnel src 192.168.122.96 dst 192.168.122.213
> 
> #Routing rules
> rt ipv4 dst
> 192.168.122.0/24<https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__192.168.122.0_24&d=DwMFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=jPfB8
> rwwviRSxyLWs2n6B-
> WYLn1v9SyTMrT5EQqh2TU&m=UljpWEF8dI3bZcYKgM0AqP1ViNQsN-
> w4rZ1ZvTPc9Fw&s=UR36mFZdcNaE_w6k-
> jBS_XvmgSgAQzga2yAHh2jrIl4&e=> port 1
> 
> On Tue, 18 Aug, 2020, 4:29 pm Anoob Joseph,
> <anoobj@marvell.com<mailto:anoobj@marvell.com>> wrote:
> Hi Satya,
> 
> Are you attempting to enable inline protocol (IPsec) functionality? If yes,
> which PMD (& h/w) are you using for the same?
> 
> Thanks,
> Anoob
> 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org<mailto:dev-bounces@dpdk.org>> On
> > Behalf Of satyavalli rama
> > Sent: Tuesday, August 18, 2020 4:08 PM
> > To: dev@dpdk.org<mailto:dev@dpdk.org>;
> > users@dpdk.org<mailto:users@dpdk.org>
> > Subject: Re: [dpdk-dev] Ipsec-secgw packet processing
> >
> > We further debugged and we observed that while running ipsec-secgw
> > application in transport-mode dpdk-19.02/11, we found that inline
> > packet processing is not happening.
> > We observed that ol_flags is not setting from driver level. We are
> > expecting that , because of ol_flags not set , inline packet
> > processing is not happening.Any idea What could be the reason for
> > this, I think ol_flags will be configured from driver level Or else do
> > we need to provide any external configuration for setting ol_flags.
> > And also we are not observing encrypt/decrypt packets on pdump before
> > sending packets out from tx-port(rte_eth_tx_burst()).
> > Please help us on this...to proceed further.
> >
> > Thanks & Regards
> > Satya
> >
> >
> >
> > On Mon, 17 Aug, 2020, 4:11 pm satyavalli rama,
> > <satyavalli.rama@gmail.com<mailto:satyavalli.rama@gmail.com>>
> > wrote:
> >
> > >
> > > Hello,
> > >
> > > While we are running ipsec-secgw application in transport-mode on
> > > dpdk-19.02, we found that inline packet processing is not happening.
> > >
> > > And also we are not observing any encrypt/decrypt packets on pdump
> > > before sending packets out from tx-port(rte_eth_tx_burst()).
> > >
> > > Please help us on how to proceed further.
> > >
> > > Thanks,
> > > Jagadeesh
> > >
> > >

  reply	other threads:[~2020-09-01 11:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAMJ3rejJ4_7bYrZ1=kAsWds4A53UNBVePNdVCGpr3BDzAWAsSA@mail.gmail.com>
     [not found] ` <CAMJ3rejbOZ5mzOYyNPFqVk-Scs7CTaVZLUQOd-GMnVpaYf+pmg@mail.gmail.com>
2020-01-06  5:55   ` [dpdk-dev] Fwd: l2fwd application are not sending continuous packets satyavalli rama
2020-01-06  7:07     ` [dpdk-dev] " satyavalli rama
2020-01-09  1:55     ` satyavalli rama
2020-01-09  6:12       ` Stephen Hemminger
2020-01-09 10:34         ` satyavalli rama
2020-08-17 10:41     ` [dpdk-dev] Ipsec-secgw packet processing satyavalli rama
2020-08-18 10:37       ` satyavalli rama
2020-08-18 10:59         ` Anoob Joseph
2020-08-19 11:08           ` satyavalli rama
2020-08-26 11:23             ` satyavalli rama
2020-08-31  5:17               ` [dpdk-dev] [EXT] " Anoob Joseph
2020-08-31 12:47                 ` Pathak, Pravin
2020-09-01 11:07                   ` Iremonger, Bernard [this message]
2020-08-28 18:06             ` [dpdk-dev] " satyavalli rama

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=DM6PR11MB253793F0C88379A0A794E5BDEF2E0@DM6PR11MB2537.namprd11.prod.outlook.com \
    --to=bernard.iremonger@intel.com \
    --cc=anoobj@marvell.com \
    --cc=dev@dpdk.org \
    --cc=pravin.pathak@intel.com \
    --cc=satyavalli.rama@gmail.com \
    --cc=users@dpdk.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 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).