[dpdk-users] l2fwd application are not sending continuous packets .

[dpdk-users] l2fwd application are not sending continuous packets .

[Rohit kamble]

Hello Dpdk Team,

I'm facing issue while forwarding packets in DPDK's l2fwd application.
While sending 1 Lac packets from Scapy, I could see sometimes packets are
sending from one VM to another VM.
Before explaining issue let me explain topology.



*Topology :-=======*1) I am having 4 VMs(Virtual Machines) in same host.
All these VM are running on Ubuntu 16.04.1.
2) VM-1 is used as Scapy to forward packets (Scapy version 2.4.3) . While
creating packets I am giving destination mac(d-mac) address of VM-1.
3) In VM-2 am running L2 forwarding application.
    In this l2fwd application, I am doing simple packet forwarding by
statically keeping mac address of VM-3.
Code :-
     l2fwd_mac_updating () {
   ...
   ......
   .......
      *((uint64_t *)tmp) = 0xddccbbaa/*VM-3 mac address*/ +
((uint64_t)dest_portid << 40);
     }
4) Also in VM-3, I am doing same like VM-2, but I kept mac address of VM-4
5) In VM-4, I am using wireshark to see packets coming from VM-3.
6) In VM-2 and VM-3, I kept promiscuous mode off by commenting out
rte_eth_promiscuous_enable().

   ---------------                                   ---------------------
                         ------------------
------------------------
   |    VM-1  |      ---------->                |       VM-2     |
---------------->   |     VM-3    |       ------------------> |        VM-4
     |
   ---------------                                   ---------------------
                         ------------------
------------------------
        Scapy                              Simple L2 forwarding
      Simple L2 forwarding                        Wireshark
used for sending packets            Sending all packets to
 Sending all packets to
                                                            VM-3
                        VM-4
                                                          (DPDK)
                     (DPDK)


*Problem :- ======*==
From scapy VM, I am sending 1 lac packets with rate of 100 packets per
second. *During problematic condition I could see packets are not getting
forward from VM-3.**Problematic state is happening anytime after sending 1k
packets.*
This issue is not consistence but I could see this issue 8 out of 10 times.


* Debugging and Observations :-=========================*
When I tried to debug this issue , I could see that
1) In problematic state, rx queue of VM-3 is not getting packets, but VM-2
is sending packets properly. I checked this by using pdump of rx queue.
2) Just before problematic state in VM-3, I could see that  previous
packet(only one packet) instead of going to VM-4, it is coming back to
again in rx queue of VM-3 and after wards I did not get any packets in rx
queue.
3) I have changed rate of packet forward 10packets per second. but still
see the issue.


*Can anyone please help to solve this problem ? I need it urgently .*
Thanks,
Rohit

[dpdk-users] Fwd: l2fwd application are not sending continuous packets .

[satyavalli rama]

Hello Dpdk Team,

I'm facing issue while forwarding packets in DPDK's l2fwd application.
While sending 1 Lac packets from Scapy, I could see sometimes packets are
sending from one VM to another VM.
Before explaining issue let me explain topology.



*Topology :-=======*1) I am having 4 VMs(Virtual Machines) in same host.
All these VM are running on Ubuntu 16.04.1.
2) VM-1 is used as Scapy to forward packets (Scapy version 2.4.3) . While
creating packets I am giving destination mac(d-mac) address of VM-1.
3) In VM-2 am running L2 forwarding application.
    In this l2fwd application, I am doing simple packet forwarding by
statically keeping mac address of VM-3.
Code :-
     l2fwd_mac_updating () {
   ...
   ......
   .......
      *((uint64_t *)tmp) = 0xddccbbaa/*VM-3 mac address*/ +
((uint64_t)dest_portid << 40);
     }
4) Also in VM-3, I am doing same like VM-2, but I kept mac address of VM-4
5) In VM-4, I am using wireshark to see packets coming from VM-3.
6) In VM-2 and VM-3, I kept promiscuous mode off by commenting out
rte_eth_promiscuous_enable().

   ---------------                                   ---------------------
                         ------------------
------------------------
   |    VM-1  |      ---------->                |       VM-2     |
---------------->   |     VM-3    |       ------------------> |        VM-4
     |
   ---------------                                   ---------------------
                         ------------------
------------------------
        Scapy                              Simple L2 forwarding
      Simple L2 forwarding                        Wireshark
used for sending packets            Sending all packets to
 Sending all packets to
                                                            VM-3
                        VM-4
                                                          (DPDK)
                     (DPDK)


*Problem :- ======*==
From scapy VM, I am sending 1 lac packets with rate of 100 packets per
second. *During problematic condition I could see packets are not getting
forward from VM-3.**Problematic state is happening anytime after sending 1k
packets.*
This issue is not consistence but I could see this issue 8 out of 10 times.


* Debugging and Observations :-=========================*
When I tried to debug this issue , I could see that
1) In problematic state, rx queue of VM-3 is not getting packets, but VM-2
is sending packets properly. I checked this by using pdump of rx queue.
2) Just before problematic state in VM-3, I could see that  previous
packet(only one packet) instead of going to VM-4, it is coming back to
again in rx queue of VM-3 and after wards I did not get any packets in rx
queue.
3) I have changed rate of packet forward 10packets per second. but still
see the issue.


*Can anyone please help to solve this problem ? I need it urgently .*
Thanks,
Satya

[dpdk-users] l2fwd application are not sending continuous packets .

[satyavalli rama]

Hello Dpdk Team,

I'm facing issue while forwarding packets in DPDK's l2fwd application.
While sending 1 Lac packets from Scapy, I could see sometimes packets are
sending from one VM to another VM.
Before explaining issue let me explain topology.



*Topology :-=======*1) I am having 4 VMs(Virtual Machines) in same host.
All these VM are running on Ubuntu 16.04.1.
2) VM-1 is used as Scapy to forward packets (Scapy version 2.4.3) . While
creating packets I am giving destination mac(d-mac) address of VM-1.
3) In VM-2 am running L2 forwarding application.
    In this l2fwd application, I am doing simple packet forwarding by
statically keeping mac address of VM-3.
Code :-
     l2fwd_mac_updating () {
   ...
   ......
   .......
      *((uint64_t *)tmp) = 0xddccbbaa/*VM-3 mac address*/ +
((uint64_t)dest_portid << 40);
     }
4) Also in VM-3, I am doing same like VM-2, but I kept mac address of VM-4
5) In VM-4, I am using wireshark to see packets coming from VM-3.
6) In VM-2 and VM-3, I kept promiscuous mode off by commenting out
rte_eth_promiscuous_enable().

   ---------------                                   ---------------------
                         ------------------
------------------------
   |    VM-1  |      ---------->                |       VM-2     |
---------------->   |     VM-3    |       ------------------> |        VM-4
     |
   ---------------                                   ---------------------
                         ------------------
------------------------
        Scapy                              Simple L2 forwarding
      Simple L2 forwarding                        Wireshark
used for sending packets            Sending all packets to
 Sending all packets to
                                                            VM-3
                        VM-4
                                                          (DPDK)
                     (DPDK)


*Problem :- ======*==
From scapy VM, I am sending 1 lac packets with rate of 100 packets per
second. *During problematic condition I could see packets are not getting
forward from VM-3.**Problematic state is happening anytime after sending 1k
packets.*
This issue is not consistence but I could see this issue 8 out of 10 times.


* Debugging and Observations :-=========================*
When I tried to debug this issue , I could see that
1) In problematic state, rx queue of VM-3 is not getting packets, but VM-2
is sending packets properly. I checked this by using pdump of rx queue.
2) Just before problematic state in VM-3, I could see that  previous
packet(only one packet) instead of going to VM-4, it is coming back to
again in rx queue of VM-3 and after wards I did not get any packets in rx
queue.
3) I have changed rate of packet forward 10packets per second. but still
see the issue.


*Can anyone please help to solve this problem ? I need it urgently .*
Thanks,
Satya

Re: [dpdk-users] l2fwd application are not sending continuous packets .

[satyavalli rama]

Can anyone please help us with this?


On Mon, Jan 6, 2020, 11:25 satyavalli rama <satyavalli.rama@gmail.com>
wrote:

>
>
>
> Hello Dpdk Team,
>
> I'm facing issue while forwarding packets in DPDK's l2fwd application.
> While sending 1 Lac packets from Scapy, I could see sometimes packets are
> sending from one VM to another VM.
> Before explaining issue let me explain topology.
>
>
>
> *Topology :-=======*1) I am having 4 VMs(Virtual Machines) in same host.
> All these VM are running on Ubuntu 16.04.1.
> 2) VM-1 is used as Scapy to forward packets (Scapy version 2.4.3) . While
> creating packets I am giving destination mac(d-mac) address of VM-1.
> 3) In VM-2 am running L2 forwarding application.
>     In this l2fwd application, I am doing simple packet forwarding by
> statically keeping mac address of VM-3.
> Code :-
>      l2fwd_mac_updating () {
>    ...
>    ......
>    .......
>       *((uint64_t *)tmp) = 0xddccbbaa/*VM-3 mac address*/ +
> ((uint64_t)dest_portid << 40);
>      }
> 4) Also in VM-3, I am doing same like VM-2, but I kept mac address of VM-4
> 5) In VM-4, I am using wireshark to see packets coming from VM-3.
> 6) In VM-2 and VM-3, I kept promiscuous mode off by commenting out
> rte_eth_promiscuous_enable().
>
>    ---------------                                   ---------------------
>                          ------------------
> ------------------------
>    |    VM-1  |      ---------->                |       VM-2     |
> ---------------->   |     VM-3    |       ------------------> |        VM-4
>      |
>    ---------------                                   ---------------------
>                          ------------------
> ------------------------
>         Scapy                              Simple L2 forwarding
>         Simple L2 forwarding                        Wireshark
> used for sending packets            Sending all packets to
>  Sending all packets to
>                                                             VM-3
>                         VM-4
>                                                           (DPDK)
>                      (DPDK)
>
>
> *Problem :- ======*==
> From scapy VM, I am sending 1 lac packets with rate of 100 packets per
> second. *During problematic condition I could see packets are not getting
> forward from VM-3.**Problematic state is happening anytime after sending
> 1k packets.*
> This issue is not consistence but I could see this issue 8 out of 10 times.
>
>
> * Debugging and Observations :-=========================*
> When I tried to debug this issue , I could see that
> 1) In problematic state, rx queue of VM-3 is not getting packets, but VM-2
> is sending packets properly. I checked this by using pdump of rx queue.
> 2) Just before problematic state in VM-3, I could see that  previous
> packet(only one packet) instead of going to VM-4, it is coming back to
> again in rx queue of VM-3 and after wards I did not get any packets in rx
> queue.
> 3) I have changed rate of packet forward 10packets per second. but still
> see the issue.
>
>
> *Can anyone please help to solve this problem ? I need it urgently .*
> Thanks,
> Satya
>

Re: [dpdk-users] [dpdk-dev] l2fwd application are not sending continuous packets .

[Stephen Hemminger]

On Thu, 9 Jan 2020 07:25:45 +0530
satyavalli rama <satyavalli.rama@gmail.com> wrote:

> Can anyone please help us with this?
> 
> 
> On Mon, Jan 6, 2020, 11:25 satyavalli rama <satyavalli.rama@gmail.com>
> wrote:
> 
> >
> >
> >
> > Hello Dpdk Team,
> >
> > I'm facing issue while forwarding packets in DPDK's l2fwd application.
> > While sending 1 Lac packets from Scapy, I could see sometimes packets are
> > sending from one VM to another VM.
> > Before explaining issue let me explain topology.
> >
> >
> >
> > *Topology :-=======*1) I am having 4 VMs(Virtual Machines) in same host.
> > All these VM are running on Ubuntu 16.04.1.
> > 2) VM-1 is used as Scapy to forward packets (Scapy version 2.4.3) . While
> > creating packets I am giving destination mac(d-mac) address of VM-1.
> > 3) In VM-2 am running L2 forwarding application.
> >     In this l2fwd application, I am doing simple packet forwarding by
> > statically keeping mac address of VM-3.
> > Code :-
> >      l2fwd_mac_updating () {
> >    ...
> >    ......
> >    .......
> >       *((uint64_t *)tmp) = 0xddccbbaa/*VM-3 mac address*/ +
> > ((uint64_t)dest_portid << 40);
> >      }
> > 4) Also in VM-3, I am doing same like VM-2, but I kept mac address of VM-4
> > 5) In VM-4, I am using wireshark to see packets coming from VM-3.
> > 6) In VM-2 and VM-3, I kept promiscuous mode off by commenting out
> > rte_eth_promiscuous_enable().
> >
> >    ---------------                                   ---------------------
> >                          ------------------
> > ------------------------
> >    |    VM-1  |      ---------->                |       VM-2     |  
> > ---------------->   |     VM-3    |       ------------------> |        VM-4  
> >      |
> >    ---------------                                   ---------------------
> >                          ------------------
> > ------------------------
> >         Scapy                              Simple L2 forwarding
> >         Simple L2 forwarding                        Wireshark
> > used for sending packets            Sending all packets to
> >  Sending all packets to
> >                                                             VM-3
> >                         VM-4
> >                                                           (DPDK)
> >                      (DPDK)
> >
> >
> > *Problem :- ======*==
> > From scapy VM, I am sending 1 lac packets with rate of 100 packets per
> > second. *During problematic condition I could see packets are not getting
> > forward from VM-3.**Problematic state is happening anytime after sending
> > 1k packets.*
> > This issue is not consistence but I could see this issue 8 out of 10 times.
> >
> >
> > * Debugging and Observations :-=========================*
> > When I tried to debug this issue , I could see that
> > 1) In problematic state, rx queue of VM-3 is not getting packets, but VM-2
> > is sending packets properly. I checked this by using pdump of rx queue.
> > 2) Just before problematic state in VM-3, I could see that  previous
> > packet(only one packet) instead of going to VM-4, it is coming back to
> > again in rx queue of VM-3 and after wards I did not get any packets in rx
> > queue.
> > 3) I have changed rate of packet forward 10packets per second. but still
> > see the issue.
> >
> >
> > *Can anyone please help to solve this problem ? I need it urgently .*
> > Thanks,
> > Satya
> >  

Sorry, you need to dig inside the forwarding application and instrument
what is coming in and how packets are being processed. You usually can't
treat DPDK as a black box.

Re: [dpdk-users] [dpdk-dev] l2fwd application are not sending continuous packets .

[satyavalli rama]

Thanks Stephen,
We've tried to debug issue in couple of ways, please correct us whether
these approaches or right not wrong?
1. We have increased the MAX_PKT_BURST from 32 to 64 and
MEMEPOOL_CAHCE_SIZE 256 to 512
2. Keeping IGB_UIO as the only driver module.
3. Resetting the RX queues.
But still we are seeing the issue, as mentioned above========
> > * Debugging and Observations :-=========================*
> > When I tried to debug this issue , I could see that
> > 1) In problematic state, rx queue of VM-3 is not getting packets, but
VM-2
> > is sending packets properly. I checked this by using pdump of rx queue.
> > 2) Just before problematic state in VM-3, I could see that  previous
> > packet(only one packet) instead of going to VM-4, it is coming back to
> > again in rx queue of VM-3 and after wards I did not get any packets in
rx
> > queue.


On Thu, Jan 9, 2020, 11:42 Stephen Hemminger <stephen@networkplumber.org>
wrote:

> On Thu, 9 Jan 2020 07:25:45 +0530
> satyavalli rama <satyavalli.rama@gmail.com> wrote:
>
> > Can anyone please help us with this?
> >
> >
> > On Mon, Jan 6, 2020, 11:25 satyavalli rama <satyavalli.rama@gmail.com>
> > wrote:
> >
> > >
> > >
> > >
> > > Hello Dpdk Team,
> > >
> > > I'm facing issue while forwarding packets in DPDK's l2fwd application.
> > > While sending 1 Lac packets from Scapy, I could see sometimes packets
> are
> > > sending from one VM to another VM.
> > > Before explaining issue let me explain topology.
> > >
> > >
> > >
> > > *Topology :-=======*1) I am having 4 VMs(Virtual Machines) in same
> host.
> > > All these VM are running on Ubuntu 16.04.1.
> > > 2) VM-1 is used as Scapy to forward packets (Scapy version 2.4.3) .
> While
> > > creating packets I am giving destination mac(d-mac) address of VM-1.
> > > 3) In VM-2 am running L2 forwarding application.
> > >     In this l2fwd application, I am doing simple packet forwarding by
> > > statically keeping mac address of VM-3.
> > > Code :-
> > >      l2fwd_mac_updating () {
> > >    ...
> > >    ......
> > >    .......
> > >       *((uint64_t *)tmp) = 0xddccbbaa/*VM-3 mac address*/ +
> > > ((uint64_t)dest_portid << 40);
> > >      }
> > > 4) Also in VM-3, I am doing same like VM-2, but I kept mac address of
> VM-4
> > > 5) In VM-4, I am using wireshark to see packets coming from VM-3.
> > > 6) In VM-2 and VM-3, I kept promiscuous mode off by commenting out
> > > rte_eth_promiscuous_enable().
> > >
> > >    ---------------
>  ---------------------
> > >                          ------------------
> > > ------------------------
> > >    |    VM-1  |      ---------->                |       VM-2     |
> > > ---------------->   |     VM-3    |       ------------------> |
> VM-4
> > >      |
> > >    ---------------
>  ---------------------
> > >                          ------------------
> > > ------------------------
> > >         Scapy                              Simple L2 forwarding
> > >         Simple L2 forwarding                        Wireshark
> > > used for sending packets            Sending all packets to
> > >  Sending all packets to
> > >                                                             VM-3
> > >                         VM-4
> > >                                                           (DPDK)
> > >                      (DPDK)
> > >
> > >
> > > *Problem :- ======*==
> > > From scapy VM, I am sending 1 lac packets with rate of 100 packets per
> > > second. *During problematic condition I could see packets are not
> getting
> > > forward from VM-3.**Problematic state is happening anytime after
> sending
> > > 1k packets.*
> > > This issue is not consistence but I could see this issue 8 out of 10
> times.
> > >
> > >
> > > * Debugging and Observations :-=========================*
> > > When I tried to debug this issue , I could see that
> > > 1) In problematic state, rx queue of VM-3 is not getting packets, but
> VM-2
> > > is sending packets properly. I checked this by using pdump of rx queue.
> > > 2) Just before problematic state in VM-3, I could see that  previous
> > > packet(only one packet) instead of going to VM-4, it is coming back to
> > > again in rx queue of VM-3 and after wards I did not get any packets in
> rx
> > > queue.
> > > 3) I have changed rate of packet forward 10packets per second. but
> still
> > > see the issue.
> > >
> > >
> > > *Can anyone please help to solve this problem ? I need it urgently .*
> > > Thanks,
> > > Satya
> > >
>
> Sorry, you need to dig inside the forwarding application and instrument
> what is coming in and how packets are being processed. You usually can't
> treat DPDK as a black box.
>

[dpdk-users] Ipsec-secgw packet processing

[satyavalli rama]

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

Re: [dpdk-users] Ipsec-secgw packet processing

[satyavalli rama]

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

Re: [dpdk-users] [dpdk-dev] Ipsec-secgw packet processing

[Anoob Joseph]

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> On Behalf Of satyavalli rama
> Sent: Tuesday, August 18, 2020 4:08 PM
> To: dev@dpdk.org; 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>
> 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
> >
> >

Re: [dpdk-users] [dpdk-dev] Ipsec-secgw packet processing

[satyavalli rama]

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 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 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 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 port 1

On Tue, 18 Aug, 2020, 4:29 pm Anoob Joseph, <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> On Behalf Of satyavalli rama
> > Sent: Tuesday, August 18, 2020 4:08 PM
> > To: dev@dpdk.org; 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>
> > 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
> > >
> > >
>

Re: [dpdk-users] [dpdk-dev] Ipsec-secgw packet processing

[satyavalli rama]

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>
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 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 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 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 port 1
>
> On Tue, 18 Aug, 2020, 4:29 pm Anoob Joseph, <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> On Behalf Of satyavalli rama
>> > Sent: Tuesday, August 18, 2020 4:08 PM
>> > To: dev@dpdk.org; 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>
>> > 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
>> > >
>> > >
>>
>

Re: [dpdk-users] [EXT] Re: [dpdk-dev] Ipsec-secgw packet processing

[Anoob Joseph]

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=jPfB8rwwviRSxyLWs2n6B-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=jPfB8rwwviRSxyLWs2n6B-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=jPfB8rwwviRSxyLWs2n6B-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=jPfB8rwwviRSxyLWs2n6B-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
> >
> >

Re: [dpdk-users] [EXT] Re: [dpdk-dev] Ipsec-secgw packet processing

[Pathak, Pravin]

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=jPfB8rwwviRSxyLWs2n6B-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=jPfB8rwwviRSxyLWs2n6B-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=jPfB8rwwviRSxyLWs2n6B-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=jPfB8rwwviRSxyLWs2n6B-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
> >
> >

Re: [dpdk-users] [dpdk-dev] [EXT] Re: Ipsec-secgw packet processing

[Iremonger, Bernard]

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