[vpp-dev] Crypto-dev schedular - Support for multiple crypto algorithms concurrently

[Jitendra Saini]

Hi All,

*Context*: Using dpdk + vpp for telecom network user plane processing
*Desired*: want to use dpdk crypto-dev scheduler to have 2 cores dedicated
for crypto operations
*Issue*: crypto devices of different types (AES_MB & AES_GCM) are not
supported concurrently.
*Query*: *Have anyone used crypto scheduler and able to support multiple
crypto device types?*

*Details:*
We want to use 4 cores in total for user plane processing with following
deployment
Core-1: vpp worker thread - downlink
Core-2 : vpp worker thread - uplink
Core-3 : crypto-slave-1 (Cipher: aes-cbc-128)
Core-4 : crypto-slave-2 (Cipher: aes-gcm-128)

*Configurations:*
vdev crypto_aesni_mb_pmd1,name=aesni_mb_1,socket_id=0
vdev crypto_aesni_gcm_pmd1,name=aesni_gcm_1,socket_id=0
vdev
crypto_scheduler,slave=aesni_mb_1,slave=aesni_gcm_1,mode=multi-core,corelist=3-4,ordering=enable,slave_buff_size=8192

vpp# *sh dpdk crypto devices*
aesni_mb_1   crypto_aesni_mb up
  numa_node 0, max_queues 8
  free_resources 2, used_resources 2
  SYMMETRIC_CRYPTO, SYM_OPERATION_CHAINING, CPU_AVX2, CPU_AESNI
  Cipher: aes-cbc-128, aes-cbc-192, aes-cbc-256, aes-ctr-128, aes-ctr-192,
aes-ctr-256
  Auth: md5-96, sha1-96, sha-256-128, sha-384-192, sha-512-256,
aes-xcbc-mac-96

aesni_gcm_1  crypto_aesni_gcmup
  numa_node 0, max_queues 8
  free_resources 2, used_resources 2
  SYMMETRIC_CRYPTO, SYM_OPERATION_CHAINING, CPU_AVX2, CPU_AESNI,
MBUF_SCATTER_GATHER
  Cipher: aes-gcm-128, aes-gcm-192, aes-gcm-256
  Auth: aes-gmac-128, aes-gmac-256

crypto_scheduler crypto_schedulerup
  numa_node 0, max_queues 8
  free_resources 2, used_resources 2
  SYMMETRIC_CRYPTO, SYM_OPERATION_CHAINING, CPU_AVX2, CPU_AESNI,
MBUF_SCATTER_GATHER
  Cipher: aes-gcm-128, aes-gcm-192, aes-gcm-256
  Auth:


vpp# *sh dpdk crypto placement verbose*
Thread 1 (vpp_wk_0):
  aesni_mb_1   dev-id  0 inbound-queue  0 outbound-queue  1
Cipher: aes-cbc-128, aes-cbc-192, aes-cbc-256, aes-ctr-128,
aes-ctr-192, aes-ctr-256
Auth: md5-96, sha1-96, sha-256-128, sha-384-192, sha-512-256,
aes-xcbc-mac-96
  aesni_gcm_1  dev-id  1 inbound-queue  0 outbound-queue  1
Cipher:
Auth: aes-gmac-128, aes-gmac-256
  crypto_scheduler dev-id  2 inbound-queue  0 outbound-queue  1
Cipher: aes-gcm-128, aes-gcm-192, aes-gcm-256
Auth:

Thread 2 (vpp_wk_1):
  aesni_mb_1   dev-id  0 inbound-queue  2 outbound-queue  3
Cipher: aes-cbc-128, aes-cbc-192, aes-cbc-256, aes-ctr-128,
aes-ctr-192, aes-ctr-256
Auth: md5-96, sha1-96, sha-256-128, sha-384-192, sha-512-256,
aes-xcbc-mac-96
  aesni_gcm_1  dev-id  1 inbound-queue  2 outbound-queue  3
Cipher:
Auth: aes-gmac-128, aes-gmac-256
  crypto_scheduler dev-id  2 inbound-queue  2 outbound-queue  3
Cipher: aes-gcm-128, aes-gcm-192, aes-gcm-256
Auth:

*Query - Detail *: with above log output, we see crypto-slaves aesni_mb_1
&  aesni_gcm_1 deployed on both worker threads but from Test Results we see
following -
AES Traffic - works through crypto scehdular
GCM Traffic - does not work. (Error - dpdk-esp-decryptFailed to
get crypto session)

Can someone please help to understand this behavior / suggest if any
approach worked for you to support multiple crypto algorithms?

Thanks in advance

Best Regads,
Jitendra
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12878): https://lists.fd.io/g/vpp-dev/message/12878
Mute This Topic: https://lists.fd.io/mt/31417484/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Question about ipsec policy

[Zhang Yuwei]

Hi Guys,
 I have a question about ipsec policy in VPP. From my testing and deep 
into the code, I found there's a no confliction detection and resolving in 
current implementation for ipsec policy which means I could add two polices 
with some overlap area with same priority. Should we add some mechanism to 
solve this issue or the behavior to the packets which match the two policies 
will be undefined, what do you think? Thanks.

Regards
Yuwei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12877): https://lists.fd.io/g/vpp-dev/message/12877
Mute This Topic: https://lists.fd.io/mt/31417445/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] how to trace tcp4-output?

[Florin Coras]

Sure, that’s a good option. But, the point is that the stack won’t try to 
figure out if the output interface is actually capable of honoring the 
“offload” flag. Still need to think if this could be handled better.

Also, note that the stack handles segmentation itself, it does not offload 
rx/tx re-assembly/segmentation. 

Florin

> On Apr 29, 2019, at 9:38 AM, Andreas Schultz  
> wrote:
> 
> Am Mo., 29. Apr. 2019 um 18:21 Uhr schrieb Florin Coras 
> mailto:fcoras.li...@gmail.com>>:
> Unfortunately, as things stand, the tunnel should compute the checksum before 
> encapsulating the traffic. Otherwise the output node won’t be able to find 
> the right headers. 
> 
> Will look into simplifying this. 
> 
> I have look into it a bit more. If I had used a midchain-adjacency instead it 
> should would. The midchain rewrite processing seems be handling the check 
> sums and also segmentation.
> 
> Andreas
> 
> 
> Florin
> 
>> On Apr 29, 2019, at 8:18 AM, Andreas Schultz > > wrote:
>> 
>> Thanks, that helped a lot. I found that traffic is not passing through the 
>> node as I expected it.
>> 
>> The actual graph is
>> 
>>tcp4-output -> ip4-lookup -> ip4-rewrite -> upf-if-input
>> 
>> Note: upf-if-input is the node function of an interface. It is found through 
>> a fib entry that look like this:
>> 
>> 10.106.14.227/32 
>>   unicast-ip4-chain
>>   [@0]: dpo-load-balance: [proto:ip4 index:38 buckets:1 uRPF:43 to:[0:0]]
>> [0] [@5]: ipv4 via 0.0.0.0 upf_session1: mtu:9000
>> 
>> What I was expecting that between ip4-rewrite and upf-if-input the 
>> vnet_interface_output_node function of the software interface would be 
>> invoked.
>> 
>> As far as I can see that is the only logical place that would calculate 
>> check sums and do segmentation on for software interfaces.
>> For routed traffic that is normally not needed, but locally generated 
>> traffic (like a local TCP endpoint) needs it.
>> 
>> It feels like I'm missing a important piece of the picture here.
>> What function or node should fill in the checksum for locally generate 
>> traffic before it is encapsulated into a tunnel and what might be wrong that 
>> it does not work in my setup?
>> 
>> Many Thanks,
>> Andreas
>> 
>> Am Mo., 29. Apr. 2019 um 16:59 Uhr schrieb Dave Barach (dbarach) 
>> mailto:dbar...@cisco.com>>:
>> Try “pcap dispatch trace on max 1 buffer-trace  
>> 1000”, cause a transaction, “pcap dispatch trace off”; then look at the 
>> resulting trace w/ a vpp-dispatch-trace enabled wireshark. See 
>> https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/buildwireshark.html
>>  
>> 
>>  
>> 
>> HTH... Dave
>> 
>>  
>> 
>>  
>> 
>> From: mailto:vpp-dev@lists.fd.io>> on behalf of 
>> Andreas Schultz > >
>> Date: Monday, April 29, 2019 at 9:31 AM
>> To: "vpp-dev@lists.fd.io " > >
>> Subject: [vpp-dev] how to trace tcp4-output?
>> 
>>  
>> 
>> Hi, 
>> 
>>  
>> 
>> I'm trying to debug a problem and need to trace tcp4-output with vpp 19.04.
>> 
>>  
>> 
>> So far I have tried it with "trace add tcp4-output 100 verbose", but that is 
>> not producing the expected result. The trace buffer is always empty.
>> 
>>  
>> 
>> I was expecting that "trace add af-packet-input 100" would also trace the 
>> replies. But I can only see the incoming TCP-SYN, the generated SYN+ACK and 
>> the tcp4-output nodes are not showing up in the trace.
>> 
>> I do know that the SYN+ACK gets generate, because I can see it in tcpdump 
>> after it has gone through an encapsulation.
>> 
>>  
>> 
>> The problem I'm trying to figure out is why the TCP SYN+ACK packet when it 
>> hits a tunnel encapsulation node has invalid (or even no) check sums. I 
>> suspect there is something going on with the csum offload. But without the 
>> trace, finding that problem is a nightmare.
>> 
>>  
>> 
>> Many thanks,
>> 
>> Andreas
>> 
>>  
>> 
>>  
>> 
>> -- 
>> 
>> -- 
>> Dipl.-Inform. Andreas Schultz
>> 
>> --- enabling your networks --
>> Travelping GmbH Phone:  +49-391-81 90 99 0
>> Roentgenstr. 13 Fax:+49-391-81 90 99 299
>> 39108 Magdeburg Email:  i...@travelping.com 
>> 
>> GERMANY Web:http://www.travelping.com 
>> 
>> Company Registration: Amtsgericht StendalReg No.:   HRB 10578
>> 
>> Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
>> -
>> 
>> 
>> 
>> -- 
>> -- 
>> Dipl.-Inform. Andreas Schultz
>> 
>> --- enabling your networks --
>> Travelping GmbH Phone:  +49-391-81 90 

Re: [vpp-dev] how to trace tcp4-output?

[Andreas Schultz]

Am Mo., 29. Apr. 2019 um 18:21 Uhr schrieb Florin Coras <
fcoras.li...@gmail.com>:

> Unfortunately, as things stand, the tunnel should compute the checksum
> before encapsulating the traffic. Otherwise the output node won’t be able
> to find the right headers.
>
> Will look into simplifying this.
>

I have look into it a bit more. If I had used a midchain-adjacency instead
it should would. The midchain rewrite processing seems be handling the
check sums and also segmentation.

Andreas


> Florin
>
> On Apr 29, 2019, at 8:18 AM, Andreas Schultz <
> andreas.schu...@travelping.com> wrote:
>
> Thanks, that helped a lot. I found that traffic is not passing through the
> node as I expected it.
>
> The actual graph is
>
>tcp4-output -> ip4-lookup -> ip4-rewrite -> upf-if-input
>
> Note: upf-if-input is the node function of an interface. It is found
> through a fib entry that look like this:
>
> 10.106.14.227/32
>   unicast-ip4-chain
>   [@0]: dpo-load-balance: [proto:ip4 index:38 buckets:1 uRPF:43 to:[0:0]]
> [0] [@5]: ipv4 via 0.0.0.0 upf_session1: mtu:9000
>
> What I was expecting that between ip4-rewrite and upf-if-input
> the vnet_interface_output_node function of the software interface would be
> invoked.
>
> As far as I can see that is the only logical place that would calculate
> check sums and do segmentation on for software interfaces.
> For routed traffic that is normally not needed, but locally generated
> traffic (like a local TCP endpoint) needs it.
>
> It feels like I'm missing a important piece of the picture here.
> What function or node should fill in the checksum for locally generate
> traffic before it is encapsulated into a tunnel and what might be wrong
> that it does not work in my setup?
>
> Many Thanks,
> Andreas
>
> Am Mo., 29. Apr. 2019 um 16:59 Uhr schrieb Dave Barach (dbarach) <
> dbar...@cisco.com>:
>
>> Try “pcap dispatch trace on max 1 buffer-trace
>>  1000”, cause a transaction, “pcap dispatch trace
>> off”; then look at the resulting trace w/ a vpp-dispatch-trace enabled
>> wireshark. See
>> https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/buildwireshark.html
>>
>>
>>
>> HTH... Dave
>>
>>
>>
>>
>>
>> *From: * on behalf of Andreas Schultz <
>> andreas.schu...@travelping.com>
>> *Date: *Monday, April 29, 2019 at 9:31 AM
>> *To: *"vpp-dev@lists.fd.io" 
>> *Subject: *[vpp-dev] how to trace tcp4-output?
>>
>>
>>
>> Hi,
>>
>>
>>
>> I'm trying to debug a problem and need to trace tcp4-output with vpp
>> 19.04.
>>
>>
>>
>> So far I have tried it with "trace add tcp4-output 100 verbose", but that
>> is not producing the expected result. The trace buffer is always empty.
>>
>>
>>
>> I was expecting that "trace add af-packet-input 100" would also trace the
>> replies. But I can only see the incoming TCP-SYN, the generated SYN+ACK and
>> the tcp4-output nodes are not showing up in the trace.
>>
>> I do know that the SYN+ACK gets generate, because I can see it in tcpdump
>> after it has gone through an encapsulation.
>>
>>
>>
>> The problem I'm trying to figure out is why the TCP SYN+ACK packet when
>> it hits a tunnel encapsulation node has invalid (or even no) check sums. I
>> suspect there is something going on with the csum offload. But without the
>> trace, finding that problem is a nightmare.
>>
>>
>>
>> Many thanks,
>>
>> Andreas
>>
>>
>>
>>
>>
>> --
>>
>> --
>> Dipl.-Inform. Andreas Schultz
>>
>> --- enabling your networks --
>> Travelping GmbH Phone:  +49-391-81 90 99 0
>> Roentgenstr. 13 Fax:+49-391-81 90 99 299
>> 39108 Magdeburg Email:  i...@travelping.com
>> GERMANY Web:http://www.travelping.com
>>
>> Company Registration: Amtsgericht StendalReg No.:   HRB 10578
>>
>> Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
>> -
>>
>
>
> --
> --
> Dipl.-Inform. Andreas Schultz
>
> --- enabling your networks --
> Travelping GmbH Phone:  +49-391-81 90 99 0
> Roentgenstr. 13 Fax:+49-391-81 90 99 299
> 39108 Magdeburg Email:  i...@travelping.com
> GERMANY Web:http://www.travelping.com
>
> Company Registration: Amtsgericht StendalReg No.:   HRB 10578
> Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
> -
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#12873): https://lists.fd.io/g/vpp-dev/message/12873
> Mute This Topic: https://lists.fd.io/mt/31383412/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
>

-- 
-- 
Dipl.-Inform. Andreas Schultz

Re: [vpp-dev] how to trace tcp4-output?

[Florin Coras]

Unfortunately, as things stand, the tunnel should compute the checksum before 
encapsulating the traffic. Otherwise the output node won’t be able to find the 
right headers. 

Will look into simplifying this. 

Florin

> On Apr 29, 2019, at 8:18 AM, Andreas Schultz  
> wrote:
> 
> Thanks, that helped a lot. I found that traffic is not passing through the 
> node as I expected it.
> 
> The actual graph is
> 
>tcp4-output -> ip4-lookup -> ip4-rewrite -> upf-if-input
> 
> Note: upf-if-input is the node function of an interface. It is found through 
> a fib entry that look like this:
> 
> 10.106.14.227/32 
>   unicast-ip4-chain
>   [@0]: dpo-load-balance: [proto:ip4 index:38 buckets:1 uRPF:43 to:[0:0]]
> [0] [@5]: ipv4 via 0.0.0.0 upf_session1: mtu:9000
> 
> What I was expecting that between ip4-rewrite and upf-if-input the 
> vnet_interface_output_node function of the software interface would be 
> invoked.
> 
> As far as I can see that is the only logical place that would calculate check 
> sums and do segmentation on for software interfaces.
> For routed traffic that is normally not needed, but locally generated traffic 
> (like a local TCP endpoint) needs it.
> 
> It feels like I'm missing a important piece of the picture here.
> What function or node should fill in the checksum for locally generate 
> traffic before it is encapsulated into a tunnel and what might be wrong that 
> it does not work in my setup?
> 
> Many Thanks,
> Andreas
> 
> Am Mo., 29. Apr. 2019 um 16:59 Uhr schrieb Dave Barach (dbarach) 
> mailto:dbar...@cisco.com>>:
> Try “pcap dispatch trace on max 1 buffer-trace  
> 1000”, cause a transaction, “pcap dispatch trace off”; then look at the 
> resulting trace w/ a vpp-dispatch-trace enabled wireshark. See 
> https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/buildwireshark.html
>  
> 
>  
> 
> HTH... Dave
> 
>  
> 
>  
> 
> From: mailto:vpp-dev@lists.fd.io>> on behalf of Andreas 
> Schultz  >
> Date: Monday, April 29, 2019 at 9:31 AM
> To: "vpp-dev@lists.fd.io "  >
> Subject: [vpp-dev] how to trace tcp4-output?
> 
>  
> 
> Hi, 
> 
>  
> 
> I'm trying to debug a problem and need to trace tcp4-output with vpp 19.04.
> 
>  
> 
> So far I have tried it with "trace add tcp4-output 100 verbose", but that is 
> not producing the expected result. The trace buffer is always empty.
> 
>  
> 
> I was expecting that "trace add af-packet-input 100" would also trace the 
> replies. But I can only see the incoming TCP-SYN, the generated SYN+ACK and 
> the tcp4-output nodes are not showing up in the trace.
> 
> I do know that the SYN+ACK gets generate, because I can see it in tcpdump 
> after it has gone through an encapsulation.
> 
>  
> 
> The problem I'm trying to figure out is why the TCP SYN+ACK packet when it 
> hits a tunnel encapsulation node has invalid (or even no) check sums. I 
> suspect there is something going on with the csum offload. But without the 
> trace, finding that problem is a nightmare.
> 
>  
> 
> Many thanks,
> 
> Andreas
> 
>  
> 
>  
> 
> -- 
> 
> -- 
> Dipl.-Inform. Andreas Schultz
> 
> --- enabling your networks --
> Travelping GmbH Phone:  +49-391-81 90 99 0
> Roentgenstr. 13 Fax:+49-391-81 90 99 299
> 39108 Magdeburg Email:  i...@travelping.com 
> 
> GERMANY Web:http://www.travelping.com 
> 
> Company Registration: Amtsgericht StendalReg No.:   HRB 10578
> 
> Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
> -
> 
> 
> 
> -- 
> -- 
> Dipl.-Inform. Andreas Schultz
> 
> --- enabling your networks --
> Travelping GmbH Phone:  +49-391-81 90 99 0
> Roentgenstr. 13 Fax:+49-391-81 90 99 299
> 39108 Magdeburg Email:  i...@travelping.com 
> 
> GERMANY Web:http://www.travelping.com 
> 
> 
> Company Registration: Amtsgericht StendalReg No.:   HRB 10578
> Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
> -
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12873): https://lists.fd.io/g/vpp-dev/message/12873 
> 
> Mute This Topic: https://lists.fd.io/mt/31383412/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 

Re: [vpp-dev] how to trace tcp4-output?

[Andreas Schultz]

Thanks, that helped a lot. I found that traffic is not passing through the
node as I expected it.

The actual graph is

   tcp4-output -> ip4-lookup -> ip4-rewrite -> upf-if-input

Note: upf-if-input is the node function of an interface. It is found
through a fib entry that look like this:

10.106.14.227/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:38 buckets:1 uRPF:43 to:[0:0]]
[0] [@5]: ipv4 via 0.0.0.0 upf_session1: mtu:9000

What I was expecting that between ip4-rewrite and upf-if-input
the vnet_interface_output_node function of the software interface would be
invoked.

As far as I can see that is the only logical place that would calculate
check sums and do segmentation on for software interfaces.
For routed traffic that is normally not needed, but locally generated
traffic (like a local TCP endpoint) needs it.

It feels like I'm missing a important piece of the picture here.
What function or node should fill in the checksum for locally generate
traffic before it is encapsulated into a tunnel and what might be wrong
that it does not work in my setup?

Many Thanks,
Andreas

Am Mo., 29. Apr. 2019 um 16:59 Uhr schrieb Dave Barach (dbarach) <
dbar...@cisco.com>:

> Try “pcap dispatch trace on max 1 buffer-trace
>  1000”, cause a transaction, “pcap dispatch trace
> off”; then look at the resulting trace w/ a vpp-dispatch-trace enabled
> wireshark. See
> https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/buildwireshark.html
>
>
>
> HTH... Dave
>
>
>
>
>
> *From: * on behalf of Andreas Schultz <
> andreas.schu...@travelping.com>
> *Date: *Monday, April 29, 2019 at 9:31 AM
> *To: *"vpp-dev@lists.fd.io" 
> *Subject: *[vpp-dev] how to trace tcp4-output?
>
>
>
> Hi,
>
>
>
> I'm trying to debug a problem and need to trace tcp4-output with vpp 19.04.
>
>
>
> So far I have tried it with "trace add tcp4-output 100 verbose", but that
> is not producing the expected result. The trace buffer is always empty.
>
>
>
> I was expecting that "trace add af-packet-input 100" would also trace the
> replies. But I can only see the incoming TCP-SYN, the generated SYN+ACK and
> the tcp4-output nodes are not showing up in the trace.
>
> I do know that the SYN+ACK gets generate, because I can see it in tcpdump
> after it has gone through an encapsulation.
>
>
>
> The problem I'm trying to figure out is why the TCP SYN+ACK packet when it
> hits a tunnel encapsulation node has invalid (or even no) check sums. I
> suspect there is something going on with the csum offload. But without the
> trace, finding that problem is a nightmare.
>
>
>
> Many thanks,
>
> Andreas
>
>
>
>
>
> --
>
> --
> Dipl.-Inform. Andreas Schultz
>
> --- enabling your networks --
> Travelping GmbH Phone:  +49-391-81 90 99 0
> Roentgenstr. 13 Fax:+49-391-81 90 99 299
> 39108 Magdeburg Email:  i...@travelping.com
> GERMANY Web:http://www.travelping.com
>
> Company Registration: Amtsgericht StendalReg No.:   HRB 10578
>
> Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
> -
>


-- 
-- 
Dipl.-Inform. Andreas Schultz

--- enabling your networks --
Travelping GmbH Phone:  +49-391-81 90 99 0
Roentgenstr. 13 Fax:+49-391-81 90 99 299
39108 Magdeburg Email:  i...@travelping.com
GERMANY Web:http://www.travelping.com

Company Registration: Amtsgericht StendalReg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12873): https://lists.fd.io/g/vpp-dev/message/12873
Mute This Topic: https://lists.fd.io/mt/31383412/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] how to trace tcp4-output?

[Florin Coras]

Hi Andreas, 

The tracing should work but because we’re reusing the syn packet to build the 
syn-ack, it might not show correctly. Could you breakpoint the tcp4-output and 
try to see if the trace code is hit?

As for the checksum, tcp only tags the packet with a request to have it 
offloaded. If the nic wrongly advertises that it can do it, the offload 
infrastructure will comply with that. 

If you’re using dpdk and you want to force sw checksum computation, change 
startup conf and add "dpdk { enable-tcp-udp-checksum }”.

Hope this helps,
Florin 

> On Apr 29, 2019, at 6:31 AM, Andreas Schultz  
> wrote:
> 
> Hi,
> 
> I'm trying to debug a problem and need to trace tcp4-output with vpp 19.04.
> 
> So far I have tried it with "trace add tcp4-output 100 verbose", but that is 
> not producing the expected result. The trace buffer is always empty.
> 
> I was expecting that "trace add af-packet-input 100" would also trace the 
> replies. But I can only see the incoming TCP-SYN, the generated SYN+ACK and 
> the tcp4-output nodes are not showing up in the trace.
> I do know that the SYN+ACK gets generate, because I can see it in tcpdump 
> after it has gone through an encapsulation.
> 
> The problem I'm trying to figure out is why the TCP SYN+ACK packet when it 
> hits a tunnel encapsulation node has invalid (or even no) check sums. I 
> suspect there is something going on with the csum offload. But without the 
> trace, finding that problem is a nightmare.
> 
> Many thanks,
> Andreas
> 
> 
> -- 
> -- 
> Dipl.-Inform. Andreas Schultz
> 
> --- enabling your networks --
> Travelping GmbH Phone:  +49-391-81 90 99 0
> Roentgenstr. 13 Fax:+49-391-81 90 99 299
> 39108 Magdeburg Email:  i...@travelping.com 
> 
> GERMANY Web:http://www.travelping.com 
> 
> 
> Company Registration: Amtsgericht StendalReg No.:   HRB 10578
> Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
> -
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12869): https://lists.fd.io/g/vpp-dev/message/12869
> Mute This Topic: https://lists.fd.io/mt/31383412/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12872): https://lists.fd.io/g/vpp-dev/message/12872
Mute This Topic: https://lists.fd.io/mt/31383412/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] how to trace tcp4-output?

[Dave Barach via Lists.Fd.Io]

Try “pcap dispatch trace on max 1 buffer-trace  
1000”, cause a transaction, “pcap dispatch trace off”; then look at the 
resulting trace w/ a vpp-dispatch-trace enabled wireshark. See 
https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/buildwireshark.html

HTH... Dave


From:  on behalf of Andreas Schultz 

Date: Monday, April 29, 2019 at 9:31 AM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] how to trace tcp4-output?

Hi,

I'm trying to debug a problem and need to trace tcp4-output with vpp 19.04.

So far I have tried it with "trace add tcp4-output 100 verbose", but that is 
not producing the expected result. The trace buffer is always empty.

I was expecting that "trace add af-packet-input 100" would also trace the 
replies. But I can only see the incoming TCP-SYN, the generated SYN+ACK and the 
tcp4-output nodes are not showing up in the trace.
I do know that the SYN+ACK gets generate, because I can see it in tcpdump after 
it has gone through an encapsulation.

The problem I'm trying to figure out is why the TCP SYN+ACK packet when it hits 
a tunnel encapsulation node has invalid (or even no) check sums. I suspect 
there is something going on with the csum offload. But without the trace, 
finding that problem is a nightmare.

Many thanks,
Andreas


--
--
Dipl.-Inform. Andreas Schultz

--- enabling your networks --
Travelping GmbH Phone:  +49-391-81 90 99 0
Roentgenstr. 13 Fax:+49-391-81 90 99 299
39108 Magdeburg Email:  
i...@travelping.com
GERMANY Web:http://www.travelping.com
Company Registration: Amtsgericht StendalReg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12871): https://lists.fd.io/g/vpp-dev/message/12871
Mute This Topic: https://lists.fd.io/mt/31383412/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] backward PAPI-compatibility

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io]

Hello VPP reviewers.

When adding a comment to API flag day document,
I have stumbled upon an idea,
that is somewhat larger than the document itself.
It has to do with a weaker form of VPP backward compatibility,
specific to clients using Python API (PAPI).

Here is the relevant part of the comment [0]:

I have realized, that although VPP binary API does not support
optional arguments nor default values,
PAPI does effectively support "false" values as default.
Here, false value is zero, empty string, list of zero length,
byte array (if size is fixed) initialized to each byte being zero, and so on.
I believe it also extends to structured types, "false" means each field
has the false value of its type.
And I guess something reasonable also works for unions.

This can give PAPI a limited form of forward compatibility.
A client application using PAPI is forward compatible
(conversely, VPP API change is backward compatible with respect to such client)
iff the added fields, when called with the "false" value,
do not change the behavior
(compared to the previous VPP behavior where the fields were not defined).

The larger idea is to change the current VPP API in a way
that makes future API changes backward PAPI-compatible.
This first change will be incompatible,
so the subsequent changes do not have to be.

Of course, my motivations are from CSIT committer point of view,
and fairly selfish. Direct users of binary API will have no benefit
from such a change, and I have no idea about users of jvpp or govpp.

There are several approaches to making VPP backward PAPI-compatible,
so I have prepared few examples.

A typical way to add a new functionality to an existing API call
currently looks like this [1].
The new field sw_if_index has a special value ~0,
which restores the previous behavior.
But that value is not "false",
so this change is not backward PAPI-compatible.

There are (at least) two ways the new functionality could have been handled
in a backward PAPI-compatible way (from original call without sw_if_index).
The "hard" way [2] is slightly easier to describe and implement,
but there is also the "soft" way [3].

If VPP committers start encouraging such backward PAPI-compatible changes,
it would look better if also the current calls were converted.
Here is what would such a conversion look like,
from current to hard [4] and from current to soft [5].
Both are PAPI-incompatible, but the soft only for sw_if_index 0,
while the hard for all values except ~0.

My personal preference is to recommend the hard way for new functionality,
and the soft way for converting the existing functionality.
This goal of this e-mail is to ask VPP committers which way they prefer.

Of course, any other comments are also welcome.

Vratko.

[0] https://gerrit.fd.io/r/#/c/18356/2/docs/automating_vpp_api_flag_day.rst@94
[1] https://gerrit.fd.io/r/#/c/19233/1/src/vnet/interface.api
[2] https://gerrit.fd.io/r/#/c/19235/3/src/vnet/interface.api
[3] https://gerrit.fd.io/r/#/c/19234/2/src/vnet/interface.api
[4] https://gerrit.fd.io/r/#/c/19199/3/src/vnet/interface.api
[5] https://gerrit.fd.io/r/#/c/19198/3/src/vnet/interface.api
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12870): https://lists.fd.io/g/vpp-dev/message/12870
Mute This Topic: https://lists.fd.io/mt/31384190/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] how to trace tcp4-output?

[Andreas Schultz]

Hi,

I'm trying to debug a problem and need to trace tcp4-output with vpp 19.04.

So far I have tried it with "trace add tcp4-output 100 verbose", but that
is not producing the expected result. The trace buffer is always empty.

I was expecting that "trace add af-packet-input 100" would also trace the
replies. But I can only see the incoming TCP-SYN, the generated SYN+ACK and
the tcp4-output nodes are not showing up in the trace.
I do know that the SYN+ACK gets generate, because I can see it in tcpdump
after it has gone through an encapsulation.

The problem I'm trying to figure out is why the TCP SYN+ACK packet when it
hits a tunnel encapsulation node has invalid (or even no) check sums. I
suspect there is something going on with the csum offload. But without the
trace, finding that problem is a nightmare.

Many thanks,
Andreas


-- 
-- 
Dipl.-Inform. Andreas Schultz

--- enabling your networks --
Travelping GmbH Phone:  +49-391-81 90 99 0
Roentgenstr. 13 Fax:+49-391-81 90 99 299
39108 Magdeburg Email:  i...@travelping.com
GERMANY Web:http://www.travelping.com

Company Registration: Amtsgericht StendalReg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12869): https://lists.fd.io/g/vpp-dev/message/12869
Mute This Topic: https://lists.fd.io/mt/31383412/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Jenkins.fd.io network issues

[Jan Gelety via Lists.Fd.Io]

Hello,

We are experiencing quite a lot of network issues when running CSIT tests for 
19.04 report:

Caused: hudson.remoting.ChannelClosedException: Channel "unknown": Remote call 
on JNLP4-connect connection from 
vex-yul-rot-ingress-1.ci.codeaurora.org/10.30.48.3:41068 failed. The channel is 
closing down or has closed down

https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/13/console

Could you, please, have a look on it?

Thank you very much.

Regards,
Jan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12867): https://lists.fd.io/g/vpp-dev/message/12867
Mute This Topic: https://lists.fd.io/mt/31380682/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-