date:20200531

Re: [vpp-dev] Segmentation fault in VPP 20.05 release when using VCL VPPCOM_PROTO_UDPC #vpp-hoststack

2020-05-31 Thread Florin Coras

Hi Raj, 

Inline.

> On May 31, 2020, at 8:10 PM, Raj Kumar  wrote:
> 
> Hi Florin,
> The UDPC connections are working fine . I was making a basic mistake. For the 
> second application, I missed to export the  LD_LIBRARY_PATH to the build 
> directory because of that application was linking to the old library ( form 
> /usr/lib64).
> Now, I tried both UDP tx and rx connection ( UDP connected) . Both are 
> working fine.

FC: Great!

> 
> I have a question; all the connections originating from VPP host stack (UDP 
> tx)  are always going on the worker thread 1. Is there any way to assign 
> these connections to the different worker threads ( similar to the UDP rx) ? 
> I can not rely on the receiver ( to initiate the connection) as that is a 
> third party application. 

FC: At this time no. 

> 
> Earlier with the previous VPP release , I tried by assigning UDP tx 
> connections to the different worker threads in a round robin manner . I am 
> wondering if we can try some thing similar in the new release. 

It might just work. Let me know if you try it out. 

> 
> Also, please let me know in which VPP release, the following patches would be 
> available.

FC: The first two are part of 20.05, the third will be ported to the first 
20.05 point release. 

Regards, 
Florin

> 
> [1] https://gerrit.fd.io/r/c/vpp/+/27111 
> 
> [2] https://gerrit.fd.io/r/c/vpp/+/27106 
> 
>  [3] https://gerrit.fd.io/r/c/vpp/+/27235 
> 
> 
> 
> Here are the VPP stats -
> 
> vpp# sh app server
> Connection  App  Wrk
> [0:0][U] 2001:5b0::701:b883:31f:29e:udp6_rx[shm]  1
> [0:1][U] 2001:5b0::701:b883:31f:29e:udp6_rx[shm]  1
> vpp#
> vpp# sh app client
> Connection  App
> [1:0][U] 2001:5b0::701:b883:31f:29e:udp6_tx[shm]
> [1:1][U] 2001:5b0::701:b883:31f:29e:udp6_tx[shm]
> vpp#
> vpp# sh session verbose
> ConnectionState  Rx-f  
> Tx-f
> [0:0][U] 2001:5b0::701:b883:31f:29e:9880:12345LISTEN 0 0
> [0:1][U] 2001:5b0::701:b883:31f:29e:9881:56789LISTEN 0 0
> Thread 0: active sessions 2
> 
> ConnectionState  Rx-f  
> Tx-f
> [1:0][U] 2001:5b0::701:b883:31f:29e:9880:58199OPENED 0 
> 3999756
> [1:1][U] 2001:5b0::701:b883:31f:29e:9880:10442OPENED 0 
> 3999756
> Thread 1: active sessions 2
> 
> ConnectionState  Rx-f  
> Tx-f
> [2:0][U] 2001:5b0::701:b883:31f:29e:9881:56789OPENED 0 0
> Thread 2: active sessions 1
> Thread 3: no sessions
> 
> ConnectionState  Rx-f  
> Tx-f
> [4:0][U] 2001:5b0::701:b883:31f:29e:9880:12345OPENED 0 0
> Thread 4: active sessions 1
> 
> Thanks,
> -Raj
> 
> 
> 
> On Sun, May 31, 2020 at 7:35 PM Florin Coras  > wrote:
> Hi Raj, 
> 
> Inline.
> 
>> On May 31, 2020, at 4:07 PM, Raj Kumar > > wrote:
>> 
>> Hi Florin,
>> I was trying this test with debug binaries, but as soon as I enable the 
>> interface , vpp is crashing.
> 
> FC: It looks like somehow corrupted buffers make their way into the error 
> drop node. What traffic are you running through vpp and is this master or are 
> you running some custom code? 
> 
>> 
>> On the original problem ( multiple listener); if I open multiple sockets 
>> from the same multi threaded application then it works fine. But, if I start 
>> another application then only I see the VPP crash( which I mentioned in my 
>> previous email).
> 
> FC: Is the second app trying to listen on the same ip:port pair? That is not 
> supported and the second listen request should’ve been rejected. Do you have 
> a bt?
> 
> Regards,
> Florin
> 
>> 
>> Here is the stack trace with debug binaries which is crashing on startup. 
>> Please let me know what wrong I am doing here ? 
>> 
>> 
>> #0  0x74b748df in raise () from /lib64/libc.so.6
>> #1  0x74b5ecf5 in abort () from /lib64/libc.so.6
>> #2  0x00407a28 in os_panic () at /opt/vpp/src/vpp/vnet/main.c:366
>> #3  0x75a279af in debugger () at /opt/vpp/src/vppinfra/error.c:84
>> #4  0x75a27d92 in _clib_error (how_to_die=2, 
>> function_name=0x7663d540 <__FUNCTION__.35997> 
>> "vlib_buffer_validate_alloc_free",
>> line_number=367, fmt=0x7663d0ba "%s %U buffer 0x%x") at 
>> /opt/vpp/src/vppinfra/error.c:143
>> #5  0x765752a3 in vlib_buffer_validate_alloc_free (vm=0x76866340 
>> , buffers=0x7fffb586d630, n_buffers=1,
>> expected_state=VLIB_BUFFER_KNOWN_ALLOCATED) at 
>> /opt/vpp/src/vlib/buffer.c:366
>> #6  0x765675f0 in vlib_buffer_pool_put (vm=0x76866340 
>> ,

Re: [vpp-dev] Segmentation fault in VPP 20.05 release when using VCL VPPCOM_PROTO_UDPC #vpp-hoststack

2020-05-31 Thread Florin Coras

Hi Raj, 

Inline.

> On May 31, 2020, at 4:07 PM, Raj Kumar  wrote:
> 
> Hi Florin,
> I was trying this test with debug binaries, but as soon as I enable the 
> interface , vpp is crashing.

FC: It looks like somehow corrupted buffers make their way into the error drop 
node. What traffic are you running through vpp and is this master or are you 
running some custom code? 

> 
> On the original problem ( multiple listener); if I open multiple sockets from 
> the same multi threaded application then it works fine. But, if I start 
> another application then only I see the VPP crash( which I mentioned in my 
> previous email).

FC: Is the second app trying to listen on the same ip:port pair? That is not 
supported and the second listen request should’ve been rejected. Do you have a 
bt?

Regards,
Florin

> 
> Here is the stack trace with debug binaries which is crashing on startup. 
> Please let me know what wrong I am doing here ? 
> 
> 
> #0  0x74b748df in raise () from /lib64/libc.so.6
> #1  0x74b5ecf5 in abort () from /lib64/libc.so.6
> #2  0x00407a28 in os_panic () at /opt/vpp/src/vpp/vnet/main.c:366
> #3  0x75a279af in debugger () at /opt/vpp/src/vppinfra/error.c:84
> #4  0x75a27d92 in _clib_error (how_to_die=2, 
> function_name=0x7663d540 <__FUNCTION__.35997> 
> "vlib_buffer_validate_alloc_free",
> line_number=367, fmt=0x7663d0ba "%s %U buffer 0x%x") at 
> /opt/vpp/src/vppinfra/error.c:143
> #5  0x765752a3 in vlib_buffer_validate_alloc_free (vm=0x76866340 
> , buffers=0x7fffb586d630, n_buffers=1,
> expected_state=VLIB_BUFFER_KNOWN_ALLOCATED) at 
> /opt/vpp/src/vlib/buffer.c:366
> #6  0x765675f0 in vlib_buffer_pool_put (vm=0x76866340 
> , buffer_pool_index=0 '\000', buffers=0x7fffb586d630,
> n_buffers=1) at /opt/vpp/src/vlib/buffer_funcs.h:754
> #7  0x76567dde in vlib_buffer_free_inline (vm=0x76866340 
> , buffers=0x7fffb67e9b14, n_buffers=0, maybe_next=1)
> at /opt/vpp/src/vlib/buffer_funcs.h:924
> #8  0x76567e2e in vlib_buffer_free (vm=0x76866340 
> , buffers=0x7fffb67e9b10, n_buffers=1)
> at /opt/vpp/src/vlib/buffer_funcs.h:943
> #9  0x76568cb0 in process_drop_punt (vm=0x76866340 
> , node=0x7fffb5475e00, frame=0x7fffb67e9b00,
> disposition=ERROR_DISPOSITION_DROP) at /opt/vpp/src/vlib/drop.c:231
> #10 0x76568db0 in error_drop_node_fn_hsw (vm=0x76866340 
> , node=0x7fffb5475e00, frame=0x7fffb67e9b00)
> at /opt/vpp/src/vlib/drop.c:247
> #11 0x765c3447 in dispatch_node (vm=0x76866340 
> , node=0x7fffb5475e00, type=VLIB_NODE_TYPE_INTERNAL,
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb67e9b00, 
> last_time_stamp=15480427682338516) at /opt/vpp/src/vlib/main.c:1235
> #12 0x765c3c02 in dispatch_pending_node (vm=0x76866340 
> , pending_frame_index=2,
> last_time_stamp=15480427682338516) at /opt/vpp/src/vlib/main.c:1403
> #13 0x765c58c9 in vlib_main_or_worker_loop (vm=0x76866340 
> , is_main=1) at /opt/vpp/src/vlib/main.c:1862
> #14 0x765c6320 in vlib_main_loop (vm=0x76866340 
> ) at /opt/vpp/src/vlib/main.c:1990
> #15 0x765c70e0 in vlib_main (vm=0x76866340 , 
> input=0x7fffb586efb0) at /opt/vpp/src/vlib/main.c:2236
> #16 0x7662f311 in thread0 (arg=140737329390400) at 
> /opt/vpp/src/vlib/unix/main.c:658
> #17 0x75a465cc in clib_calljmp () at 
> /opt/vpp/src/vppinfra/longjmp.S:123
> #18 0x7fffd0a0 in ?? ()
> #19 0x7662f8a7 in vlib_unix_main (argc=50, argv=0x705f00) at 
> /opt/vpp/src/vlib/unix/main.c:730
> #20 0x00407387 in main (argc=50, argv=0x705f00) at 
> /opt/vpp/src/vpp/vnet/main.c:291
> 
> thanks,
> -Raj
> 
> On Mon, May 25, 2020 at 5:02 PM Florin Coras  > wrote:
> Hi Raj, 
> 
> Okay, so at least with that we have support for bounded listeners (note that 
> [2] was merged but to set the connected option you now have to use 
> vppcom_session_attr). 
> 
> As for the trace, something seems off. Why exactly does it crash? It looks as 
> if session_get_transport_proto (ls) crashes because of ls being null, but 
> prior to that ls is dereferenced and it does’t crash. Could you try with 
> debug binaries? 
> 
> Regards,
> Florin
> 
>> On May 25, 2020, at 1:43 PM, Raj Kumar > > wrote:
>> 
>> Hi Florin,
>> This works fine with single udp listener. I can see connections going on 
>> different cores. But, if I run more than one listener then VPP is crashing. 
>> Here are the VPP stack traces - 
>> 
>> (gdb) bt
>> #0  0x in ?? ()
>> #1  0x77761239 in session_listen (ls=, 
>> sep=sep@entry=0x7fffb557fd50) at 
>> /opt/vpp/src/vnet/session/session_types.h:247
>> #2  0x77788b3f in app_listener_alloc_and_init 
>> (app=app@entry=0x7fffb76f7d98, sep=sep@entry=0x7fffb557fd50,
>> listener=listener@entry=0x7fffb557fd28) at 
>>

Re: [vpp-dev] Segmentation fault in VPP 20.05 release when using VCL VPPCOM_PROTO_UDPC #vpp-hoststack

2020-05-31 Thread Raj Kumar

Hi Florin,
I was trying this test with debug binaries, but as soon as I enable the
interface , vpp is crashing.

On the original problem ( multiple listener); if I open multiple sockets
from the same multi threaded application then it works fine. But, if I
start another application then only I see the VPP crash( which I mentioned
in my previous email).

Here is the stack trace with debug binaries which is crashing on startup.
Please let me know what wrong I am doing here ?


#0  0x74b748df in raise () from /lib64/libc.so.6
#1  0x74b5ecf5 in abort () from /lib64/libc.so.6
#2  0x00407a28 in os_panic () at /opt/vpp/src/vpp/vnet/main.c:366
#3  0x75a279af in debugger () at /opt/vpp/src/vppinfra/error.c:84
#4  0x75a27d92 in _clib_error (how_to_die=2,
function_name=0x7663d540 <__FUNCTION__.35997>
"vlib_buffer_validate_alloc_free",
line_number=367, fmt=0x7663d0ba "%s %U buffer 0x%x") at
/opt/vpp/src/vppinfra/error.c:143
#5  0x765752a3 in vlib_buffer_validate_alloc_free
(vm=0x76866340 , buffers=0x7fffb586d630, n_buffers=1,
expected_state=VLIB_BUFFER_KNOWN_ALLOCATED) at
/opt/vpp/src/vlib/buffer.c:366
#6  0x765675f0 in vlib_buffer_pool_put (vm=0x76866340
, buffer_pool_index=0 '\000', buffers=0x7fffb586d630,
n_buffers=1) at /opt/vpp/src/vlib/buffer_funcs.h:754
#7  0x76567dde in vlib_buffer_free_inline (vm=0x76866340
, buffers=0x7fffb67e9b14, n_buffers=0, maybe_next=1)
at /opt/vpp/src/vlib/buffer_funcs.h:924
#8  0x76567e2e in vlib_buffer_free (vm=0x76866340
, buffers=0x7fffb67e9b10, n_buffers=1)
at /opt/vpp/src/vlib/buffer_funcs.h:943
#9  0x76568cb0 in process_drop_punt (vm=0x76866340
, node=0x7fffb5475e00, frame=0x7fffb67e9b00,
disposition=ERROR_DISPOSITION_DROP) at /opt/vpp/src/vlib/drop.c:231
#10 0x76568db0 in error_drop_node_fn_hsw (vm=0x76866340
, node=0x7fffb5475e00, frame=0x7fffb67e9b00)
at /opt/vpp/src/vlib/drop.c:247
#11 0x765c3447 in dispatch_node (vm=0x76866340
, node=0x7fffb5475e00, type=VLIB_NODE_TYPE_INTERNAL,
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb67e9b00,
last_time_stamp=15480427682338516) at /opt/vpp/src/vlib/main.c:1235
#12 0x765c3c02 in dispatch_pending_node (vm=0x76866340
, pending_frame_index=2,
last_time_stamp=15480427682338516) at /opt/vpp/src/vlib/main.c:1403
#13 0x765c58c9 in vlib_main_or_worker_loop (vm=0x76866340
, is_main=1) at /opt/vpp/src/vlib/main.c:1862
#14 0x765c6320 in vlib_main_loop (vm=0x76866340
) at /opt/vpp/src/vlib/main.c:1990
#15 0x765c70e0 in vlib_main (vm=0x76866340 ,
input=0x7fffb586efb0) at /opt/vpp/src/vlib/main.c:2236
#16 0x7662f311 in thread0 (arg=140737329390400) at
/opt/vpp/src/vlib/unix/main.c:658
#17 0x75a465cc in clib_calljmp () at
/opt/vpp/src/vppinfra/longjmp.S:123
#18 0x7fffd0a0 in ?? ()
#19 0x7662f8a7 in vlib_unix_main (argc=50, argv=0x705f00) at
/opt/vpp/src/vlib/unix/main.c:730
#20 0x00407387 in main (argc=50, argv=0x705f00) at
/opt/vpp/src/vpp/vnet/main.c:291

thanks,
-Raj

On Mon, May 25, 2020 at 5:02 PM Florin Coras  wrote:

> Hi Raj,
>
> Okay, so at least with that we have support for bounded listeners (note
> that [2] was merged but to set the connected option you now have to
> use vppcom_session_attr).
>
> As for the trace, something seems off. Why exactly does it crash? It looks
> as if session_get_transport_proto (ls) crashes because of ls being null,
> but prior to that ls is dereferenced and it does’t crash. Could you try
> with debug binaries?
>
> Regards,
> Florin
>
> On May 25, 2020, at 1:43 PM, Raj Kumar  wrote:
>
> Hi Florin,
> This works fine with single udp listener. I can see connections going on
> different cores. But, if I run more than one listener then VPP is crashing.
> Here are the VPP stack traces -
>
> (gdb) bt
> #0  0x in ?? ()
> #1  0x77761239 in session_listen (ls=, 
> sep=sep@entry=0x7fffb557fd50)
> at /opt/vpp/src/vnet/session/session_types.h:247
> #2  0x77788b3f in app_listener_alloc_and_init 
> (app=app@entry=0x7fffb76f7d98,
> sep=sep@entry=0x7fffb557fd50,
> listener=listener@entry=0x7fffb557fd28) at
> /opt/vpp/src/vnet/session/application.c:196
> #3  0x77788ed8 in vnet_listen (a=a@entry=0x7fffb557fd50) at
> /opt/vpp/src/vnet/session/application.c:1005
> #4  0x77779e08 in session_mq_listen_handler (data=0x1300787e9) at
> /opt/vpp/src/vnet/session/session_node.c:65
> #5  session_mq_listen_handler (data=data@entry=0x1300787e9) at
> /opt/vpp/src/vnet/session/session_node.c:36
> #6  0x77bbcdb9 in vl_api_rpc_call_t_handler (mp=0x1300787d0) at
> /opt/vpp/src/vlibmemory/vlib_api.c:520
> #7  0x77bc5ead in vl_msg_api_handler_with_vm_node 
> (am=am@entry=0x77dd2ea0
> , vlib_rp=,
> the_msg=0x1300787d0, vm=vm@entry=0x76d7c200 ,
> node=node@entry=0x7fffb553f000, is_private=is_private@entry=0

[vpp-dev] NAT44 UDP sessions are not clearing

2020-05-31 Thread carlito nueno

Hi all,

I am using vpp v20.05 and running NAT44 in end-point dependent mode.

To test NAT, I created 50k tcp and udp sessions and ran packets for 5 mins.
Then I stopped the test.

As soon as the test is stopped, tcp established sessions is 0, tcp
transitory sessions increase and all of the tcp sessions become 0 after
about 7440 seconds.
But UDP sessions are still "open", as the count is still high even after 24
hours. *As you can see below, udp LRU session timeout is around 161589 and
total udp sessions is around 29k*

Any advice? Let me know if I am missing anything.

NAT44 pool addresses:
130.44.9.8
  tenant VRF independent
  0 busy other ports
  29058 busy udp ports
  0 busy tcp ports
  0 busy icmp ports
NAT44 twice-nat pool addresses:
max translations: 400
max translations per user: 1000
udp LRU min session timeout 5175 (now 161589)
total timed out sessions: 29025
total sessions: 29058
total tcp sessions: 0
total tcp established sessions: 0
total tcp transitory sessions: 0
total tcp transitory (WAIT-CLOSED) sessions: 0
total tcp transitory (CLOSED) sessions: 0
total udp sessions: 29058
total icmp sessions: 0

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

View/Reply Online (#16588): https://lists.fd.io/g/vpp-dev/message/16588
Mute This Topic: https://lists.fd.io/mt/74589316/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] generic TCP MSS clamping

2020-05-31 Thread Miklos Tirpak

Thanks lot, Paul. I have updated the patch set.

I would appreciate a second look at the checksum around tmc_node.c:124. The 
function updates the TCP checksum instead of recalculating that now. I just 
find the usage of ip_csum_update() a bit unclear, there are also comments about 
cheating in other plugins.

Thanks,
Miklos

From: Paul Vinciguerra 
Sent: Sunday, May 31, 2020 12:05 PM
To: Miklós Tirpák 
Cc: otr...@employees.org ; Mohsin Kazmi (sykazmi) 
; vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] generic TCP MSS clamping

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Yes, please do.  My changeset only freshens the api code to take advantage of 
the refactorings that have been put in place since that code was last submitted 
and fix the tests to work properly under python3 in anticipation of your 
changes.

Paul

On Sun, May 31, 2020 at 5:23 AM Miklós Tirpák 
mailto:miklos.tir...@emnify.com>> wrote:
Hi Paul,

I just saw the updated patch from you in https://gerrit.fd.io/r/c/vpp/+/15144/2.
We discussed on the mailing list few days ago that I am working on updating 
this plugin, and your patch is a bit conflicting with my changes unfortunately.

If you do not mind I would still update the patch set in this code review with 
some more changes: RX support, bugfix in clamping (mss is changed even if it is 
low enough), some more tests, cli command updates. I hope I can do this quickly.

Thanks,
Miklos

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> on behalf of Miklos Tirpak 
via lists.fd.io 
mailto:emnify@lists.fd.io>>
Sent: Thursday, May 28, 2020 4:51 PM
To: otr...@employees.org 
mailto:otr...@employees.org>>; Mohsin Kazmi (sykazmi) 
mailto:syka...@cisco.com>>
Cc: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] generic TCP MSS clamping

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Thank you for the pointer, this is exactly what I was looking for. I will 
rebase the patch and add RX support.

Thanks,
Miklos

From: otr...@employees.org 
mailto:otr...@employees.org>>
Sent: Thursday, May 28, 2020 12:43 PM
To: Mohsin Kazmi (sykazmi) mailto:syka...@cisco.com>>
Cc: Miklós Tirpák mailto:miklos.tir...@emnify.com>>; 
vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] generic TCP MSS clamping

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Good find Mohsin. So it's only missing clamping on RX. I'm sure Miklos can add 
that.

Cheers,
Ole

> On 28 May 2020, at 12:23, Mohsin Kazmi (sykazmi) 
> mailto:syka...@cisco.com>> wrote:
>
> Hi Miklos,
>
> May be, it will help https://gerrit.fd.io/r/c/vpp/+/15144
>
> -br
> Mohsin
> From: mailto:vpp-dev@lists.fd.io>> on behalf of Ole 
> Troan mailto:otr...@employees.org>>
> Date: Thursday, May 28, 2020 at 11:23 AM
> To: Miklos Tirpak mailto:miklos.tir...@emnify.com>>
> Cc: "vpp-dev@lists.fd.io" 
> mailto:vpp-dev@lists.fd.io>>
> Subject: Re: [vpp-dev] generic TCP MSS clamping
>
> Hi Miklos,
>
> > I see the NAT plugin already supports TCP MSS clamping but it is 
> > implemented only in in2out direction.
> >
> > We have endpoints with wrong MTUs behind tunnels and not all the traffic is 
> > NATed. Hence, it would be very nice to have generic support for MSS 
> > clamping that could be enabled on the tunnel interface.
> >
> > Do you think implementing this as a feature arch would make sense? Then it 
> > would not be limited to NAT or to one kind of tunnel for example.
> > If so, what is the best place? A new plugin?
>
> A bidirectional TCP MSS adjust would be fine.
> Putting it in a plugin is likely the simplest.
>
> I'm unsure if it should be generic or not. E.g. the NAT also needs to adjust 
> the TCP checksum, and it's likely better to do it only once.
>
> Best regards,
> Ole
>

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

View/Reply Online (#16587): https://lists.fd.io/g/vpp-dev/message/16587
Mute This Topic: https://lists.fd.io/mt/74499850/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] generic TCP MSS clamping

2020-05-31 Thread Paul Vinciguerra

Yes, please do.  My changeset only freshens the api code to take advantage
of the refactorings that have been put in place since that code was last
submitted and fix the tests to work properly under python3 in anticipation
of your changes.

Paul

On Sun, May 31, 2020 at 5:23 AM Miklós Tirpák 
wrote:

> Hi Paul,
>
> I just saw the updated patch from you in
> https://gerrit.fd.io/r/c/vpp/+/15144/2.
> We discussed on the mailing list few days ago that I am working on
> updating this plugin, and your patch is a bit conflicting with my changes
> unfortunately.
>
> If you do not mind I would still update the patch set in this code review
> with some more changes: RX support, bugfix in clamping (mss is changed even
> if it is low enough), some more tests, cli command updates. I hope I can do
> this quickly.
>
> Thanks,
> Miklos
> --
> *From:* vpp-dev@lists.fd.io  on behalf of Miklos
> Tirpak via lists.fd.io 
> *Sent:* Thursday, May 28, 2020 4:51 PM
> *To:* otr...@employees.org ; Mohsin Kazmi (sykazmi)
> 
> *Cc:* vpp-dev@lists.fd.io 
> *Subject:* Re: [vpp-dev] generic TCP MSS clamping
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
> Thank you for the pointer, this is exactly what I was looking for. I will
> rebase the patch and add RX support.
>
> Thanks,
> Miklos
> --
> *From:* otr...@employees.org 
> *Sent:* Thursday, May 28, 2020 12:43 PM
> *To:* Mohsin Kazmi (sykazmi) 
> *Cc:* Miklós Tirpák ; vpp-dev@lists.fd.io <
> vpp-dev@lists.fd.io>
> *Subject:* Re: [vpp-dev] generic TCP MSS clamping
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> Good find Mohsin. So it's only missing clamping on RX. I'm sure Miklos can
> add that.
>
> Cheers,
> Ole
>
> > On 28 May 2020, at 12:23, Mohsin Kazmi (sykazmi) 
> wrote:
> >
> > Hi Miklos,
> >
> > May be, it will help https://gerrit.fd.io/r/c/vpp/+/15144
> >
> > -br
> > Mohsin
> > From:  on behalf of Ole Troan  >
> > Date: Thursday, May 28, 2020 at 11:23 AM
> > To: Miklos Tirpak 
> > Cc: "vpp-dev@lists.fd.io" 
> > Subject: Re: [vpp-dev] generic TCP MSS clamping
> >
> > Hi Miklos,
> >
> > > I see the NAT plugin already supports TCP MSS clamping but it is
> implemented only in in2out direction.
> > >
> > > We have endpoints with wrong MTUs behind tunnels and not all the
> traffic is NATed. Hence, it would be very nice to have generic support for
> MSS clamping that could be enabled on the tunnel interface.
> > >
> > > Do you think implementing this as a feature arch would make sense?
> Then it would not be limited to NAT or to one kind of tunnel for example.
> > > If so, what is the best place? A new plugin?
> >
> > A bidirectional TCP MSS adjust would be fine.
> > Putting it in a plugin is likely the simplest.
> >
> > I'm unsure if it should be generic or not. E.g. the NAT also needs to
> adjust the TCP checksum, and it's likely better to do it only once.
> >
> > Best regards,
> > Ole
> >
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16586): https://lists.fd.io/g/vpp-dev/message/16586
Mute This Topic: https://lists.fd.io/mt/74499850/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] generic TCP MSS clamping

2020-05-31 Thread Miklos Tirpak

Hi Paul,

I just saw the updated patch from you in https://gerrit.fd.io/r/c/vpp/+/15144/2.
We discussed on the mailing list few days ago that I am working on updating 
this plugin, and your patch is a bit conflicting with my changes unfortunately.

If you do not mind I would still update the patch set in this code review with 
some more changes: RX support, bugfix in clamping (mss is changed even if it is 
low enough), some more tests, cli command updates. I hope I can do this quickly.

Thanks,
Miklos

From: vpp-dev@lists.fd.io  on behalf of Miklos Tirpak via 
lists.fd.io 
Sent: Thursday, May 28, 2020 4:51 PM
To: otr...@employees.org ; Mohsin Kazmi (sykazmi) 

Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] generic TCP MSS clamping

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Thank you for the pointer, this is exactly what I was looking for. I will 
rebase the patch and add RX support.

Thanks,
Miklos

From: otr...@employees.org 
Sent: Thursday, May 28, 2020 12:43 PM
To: Mohsin Kazmi (sykazmi) 
Cc: Miklós Tirpák ; vpp-dev@lists.fd.io 

Subject: Re: [vpp-dev] generic TCP MSS clamping

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Good find Mohsin. So it's only missing clamping on RX. I'm sure Miklos can add 
that.

Cheers,
Ole

> On 28 May 2020, at 12:23, Mohsin Kazmi (sykazmi)  wrote:
>
> Hi Miklos,
>
> May be, it will help https://gerrit.fd.io/r/c/vpp/+/15144
>
> -br
> Mohsin
> From:  on behalf of Ole Troan 
> Date: Thursday, May 28, 2020 at 11:23 AM
> To: Miklos Tirpak 
> Cc: "vpp-dev@lists.fd.io" 
> Subject: Re: [vpp-dev] generic TCP MSS clamping
>
> Hi Miklos,
>
> > I see the NAT plugin already supports TCP MSS clamping but it is 
> > implemented only in in2out direction.
> >
> > We have endpoints with wrong MTUs behind tunnels and not all the traffic is 
> > NATed. Hence, it would be very nice to have generic support for MSS 
> > clamping that could be enabled on the tunnel interface.
> >
> > Do you think implementing this as a feature arch would make sense? Then it 
> > would not be limited to NAT or to one kind of tunnel for example.
> > If so, what is the best place? A new plugin?
>
> A bidirectional TCP MSS adjust would be fine.
> Putting it in a plugin is likely the simplest.
>
> I'm unsure if it should be generic or not. E.g. the NAT also needs to adjust 
> the TCP checksum, and it's likely better to do it only once.
>
> Best regards,
> Ole
>

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

View/Reply Online (#16585): https://lists.fd.io/g/vpp-dev/message/16585
Mute This Topic: https://lists.fd.io/mt/74499850/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] Segmentation fault in VPP 20.05 release when using VCL VPPCOM_PROTO_UDPC #vpp-hoststack

Re: [vpp-dev] Segmentation fault in VPP 20.05 release when using VCL VPPCOM_PROTO_UDPC #vpp-hoststack

Re: [vpp-dev] Segmentation fault in VPP 20.05 release when using VCL VPPCOM_PROTO_UDPC #vpp-hoststack

[vpp-dev] NAT44 UDP sessions are not clearing

Re: [vpp-dev] generic TCP MSS clamping

Re: [vpp-dev] generic TCP MSS clamping

Re: [vpp-dev] generic TCP MSS clamping

7 matches

Site Navigation

Mail list logo

Footer information