Re: [vpp-dev] VPP 19.04 TCP stack issue: I think TCP stack notify the FIN reception immaturely #vnet

2019-06-28 Thread guangwei
Thanks, I have a look at the patch, I think the same action should take at 
state  FIN_WAIT_1 and FIN_WAIT_2 .





At 2019-06-29 00:53:15, "Florin Coras"  wrote:
Hi, 


Well, yes. VPP tcp won’t send out of order fins because it waits for all the 
data to be acked before sending the fin. Still, others may do it, so here’s a 
quick fix for that [1]. 


Thanks,
Florin 


[1] https://gerrit.fd.io/r/c/20403/


On Jun 28, 2019, at 7:25 AM, guangwei  wrote:


I think the FIN is reported to session layer only when it's indeed all the data 
which allowed in SEQ window has received, but from code, when the packet flaged 
with FIN
no matter whether it's a Out-Of-Order segment or not , no matter whether it's 
data all in the allowed window or not, the stack will treat this FIN as normal 
case and notify the session layer. Something I missed in code ? 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13396): https://lists.fd.io/g/vpp-dev/message/13396
Mute This Topic: https://lists.fd.io/mt/32242280/675152
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480544
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 (#13402): https://lists.fd.io/g/vpp-dev/message/13402
Mute This Topic: https://lists.fd.io/mt/32242280/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] A question about TCP statck in version 19.04, when passive FIN coming in first, then APP close with TX fifo not empty, it seem can't have chance to send FIN out. #vnet

2019-06-28 Thread guangwei

Thanks.





At 2019-06-29 00:52:21, "Florin Coras"  wrote:
Here’s the patch [1]. 


Thanks, 
Florin


[1] https://gerrit.fd.io/r/c/20404/



On Jun 28, 2019, at 7:54 AM, guangwei  wrote:


Yes, please fixed it, I'am just searching the code, no environment to verify it.





At 2019-06-28 22:45:23, "Florin Coras"  wrote:
>Hi, 
>
>That is correct. You want to provide the patch or should I do it?
>
>Thanks,
>Florin
>
>> On Jun 28, 2019, at 6:10 AM, guangwei  wrote:
>> 
>> Now, I'am searching the TCP stack of VPP 19.04, and have a doubt, please 
>> look following comment in line.
>> 
>> tcp46_rcv_process_inline
>> {
>> ...
>>  /* 5: check the ACK field  */
>> ...
>>  case TCP_STATE_CLOSE_WAIT:
>>/* Do the same processing as for the ESTABLISHED state. */
>>if (tcp_rcv_ack (wrk, tc0, b0, tcp0, ))
>>  goto drop;
>>  
>>if (!(tc0->flags & TCP_CONN_FINPNDG))
>>  break;
>>  
>>/* Still have outstanding tx data */
>>if (transport_max_tx_dequeue (>connection))> think should check burst_acked  as TCP_STATE_FIN_WAIT_1 do. 
>>  break;
>>  
>>tcp_send_fin (tc0);
>>tcp_connection_timers_reset (tc0);
>>tcp_connection_set_state (tc0, TCP_STATE_LAST_ACK);
>>tcp_timer_set (tc0, TCP_TIMER_WAITCLOSE, TCP_2MSL_TIME);
>>break;
>> 
>> ...
>> 
>> }
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#13393): https://lists.fd.io/g/vpp-dev/message/13393
>> Mute This Topic: https://lists.fd.io/mt/32241597/675152
>> Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480544
>> 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 (#13398): https://lists.fd.io/g/vpp-dev/message/13398
Mute This Topic: https://lists.fd.io/mt/32241597/675152
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480544
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 (#13401): https://lists.fd.io/g/vpp-dev/message/13401
Mute This Topic: https://lists.fd.io/mt/32241597/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] VPP 19.04 TCP stack issue: I think TCP stack notify the FIN reception immaturely #vnet

2019-06-28 Thread Florin Coras
Hi, 

Well, yes. VPP tcp won’t send out of order fins because it waits for all the 
data to be acked before sending the fin. Still, others may do it, so here’s a 
quick fix for that [1]. 

Thanks,
Florin 

[1] https://gerrit.fd.io/r/c/20403/ 

> On Jun 28, 2019, at 7:25 AM, guangwei  wrote:
> 
> I think the FIN is reported to session layer only when it's indeed all the 
> data which allowed in SEQ window has received, but from code, when the packet 
> flaged with FIN
> no matter whether it's a Out-Of-Order segment or not , no matter whether it's 
> data all in the allowed window or not, the stack will treat this FIN as 
> normal case and notify the session layer. Something I missed in code ? 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13396): https://lists.fd.io/g/vpp-dev/message/13396
> Mute This Topic: https://lists.fd.io/mt/32242280/675152
> Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480544
> 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 (#13400): https://lists.fd.io/g/vpp-dev/message/13400
Mute This Topic: https://lists.fd.io/mt/32242280/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] A question about TCP statck in version 19.04, when passive FIN coming in first, then APP close with TX fifo not empty, it seem can't have chance to send FIN out. #vnet

2019-06-28 Thread Florin Coras
Here’s the patch [1]. 

Thanks, 
Florin

[1] https://gerrit.fd.io/r/c/20404/ 

> On Jun 28, 2019, at 7:54 AM, guangwei  wrote:
> 
> Yes, please fixed it, I'am just searching the code, no environment to verify 
> it.
> 
> 
> 
> At 2019-06-28 22:45:23, "Florin Coras"  wrote:
> >Hi, 
> >
> >That is correct. You want to provide the patch or should I do it?
> >
> >Thanks,
> >Florin
> >
> >> On Jun 28, 2019, at 6:10 AM, guangwei  wrote:
> >> 
> >> Now, I'am searching the TCP stack of VPP 19.04, and have a doubt, please 
> >> look following comment in line.
> >> 
> >> tcp46_rcv_process_inline
> >> {
> >> ...
> >>  /* 5: check the ACK field  */
> >> ...
> >>  case TCP_STATE_CLOSE_WAIT:
> >>/* Do the same processing as for the ESTABLISHED state. */
> >>if (tcp_rcv_ack (wrk, tc0, b0, tcp0, ))
> >>  goto drop;
> >>  
> >>if (!(tc0->flags & TCP_CONN_FINPNDG))
> >>  break;
> >>  
> >>/* Still have outstanding tx data */
> >>if (transport_max_tx_dequeue (>connection)) >> think should check burst_acked  as TCP_STATE_FIN_WAIT_1 do. 
> >>  break;
> >>  
> >>tcp_send_fin (tc0);
> >>tcp_connection_timers_reset (tc0);
> >>tcp_connection_set_state (tc0, TCP_STATE_LAST_ACK);
> >>tcp_timer_set (tc0, TCP_TIMER_WAITCLOSE, TCP_2MSL_TIME);
> >>break;
> >> 
> >> ...
> >> 
> >> }
> >> -=-=-=-=-=-=-=-=-=-=-=-
> >> Links: You receive all messages sent to this group.
> >> 
> >> View/Reply Online (#13393): https://lists.fd.io/g/vpp-dev/message/13393
> >> Mute This Topic: https://lists.fd.io/mt/32241597/675152
> >> Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480544
> >> 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 (#13398): https://lists.fd.io/g/vpp-dev/message/13398
> Mute This Topic: https://lists.fd.io/mt/32241597/675152
> Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480544
> 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 (#13399): https://lists.fd.io/g/vpp-dev/message/13399
Mute This Topic: https://lists.fd.io/mt/32241597/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] A question about TCP statck in version 19.04, when passive FIN coming in first, then APP close with TX fifo not empty, it seem can't have chance to send FIN out. #vnet

2019-06-28 Thread guangwei
Yes, please fixed it, I'am just searching the code, no environment to verify it.





At 2019-06-28 22:45:23, "Florin Coras"  wrote:
>Hi, 
>
>That is correct. You want to provide the patch or should I do it?
>
>Thanks,
>Florin
>
>> On Jun 28, 2019, at 6:10 AM, guangwei  wrote:
>> 
>> Now, I'am searching the TCP stack of VPP 19.04, and have a doubt, please 
>> look following comment in line.
>> 
>> tcp46_rcv_process_inline
>> {
>> ...
>>  /* 5: check the ACK field  */
>> ...
>>  case TCP_STATE_CLOSE_WAIT:
>>/* Do the same processing as for the ESTABLISHED state. */
>>if (tcp_rcv_ack (wrk, tc0, b0, tcp0, ))
>>  goto drop;
>>  
>>if (!(tc0->flags & TCP_CONN_FINPNDG))
>>  break;
>>  
>>/* Still have outstanding tx data */
>>if (transport_max_tx_dequeue (>connection))> think should check burst_acked  as TCP_STATE_FIN_WAIT_1 do. 
>>  break;
>>  
>>tcp_send_fin (tc0);
>>tcp_connection_timers_reset (tc0);
>>tcp_connection_set_state (tc0, TCP_STATE_LAST_ACK);
>>tcp_timer_set (tc0, TCP_TIMER_WAITCLOSE, TCP_2MSL_TIME);
>>break;
>> 
>> ...
>> 
>> }
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#13393): https://lists.fd.io/g/vpp-dev/message/13393
>> Mute This Topic: https://lists.fd.io/mt/32241597/675152
>> Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480544
>> 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 (#13398): https://lists.fd.io/g/vpp-dev/message/13398
Mute This Topic: https://lists.fd.io/mt/32241597/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] A question about TCP statck in version 19.04, when passive FIN coming in first, then APP close with TX fifo not empty, it seem can't have chance to send FIN out. #vnet

2019-06-28 Thread Florin Coras
Hi, 

That is correct. You want to provide the patch or should I do it?

Thanks,
Florin

> On Jun 28, 2019, at 6:10 AM, guangwei  wrote:
> 
> Now, I'am searching the TCP stack of VPP 19.04, and have a doubt, please look 
> following comment in line.
> 
> tcp46_rcv_process_inline
> {
> ...
>  /* 5: check the ACK field  */
> ...
>  case TCP_STATE_CLOSE_WAIT:
>/* Do the same processing as for the ESTABLISHED state. */
>if (tcp_rcv_ack (wrk, tc0, b0, tcp0, ))
>  goto drop;
>  
>if (!(tc0->flags & TCP_CONN_FINPNDG))
>  break;
>  
>/* Still have outstanding tx data */
>if (transport_max_tx_dequeue (>connection)) should check burst_acked  as TCP_STATE_FIN_WAIT_1 do. 
>  break;
>  
>tcp_send_fin (tc0);
>tcp_connection_timers_reset (tc0);
>tcp_connection_set_state (tc0, TCP_STATE_LAST_ACK);
>tcp_timer_set (tc0, TCP_TIMER_WAITCLOSE, TCP_2MSL_TIME);
>break;
> 
> ...
> 
> }
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13393): https://lists.fd.io/g/vpp-dev/message/13393
> Mute This Topic: https://lists.fd.io/mt/32241597/675152
> Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480544
> 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 (#13397): https://lists.fd.io/g/vpp-dev/message/13397
Mute This Topic: https://lists.fd.io/mt/32241597/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[vpp-dev] VPP 19.04 TCP stack issue: I think TCP stack notify the FIN reception immaturely #vnet

2019-06-28 Thread guangwei
I think the FIN is reported to session layer only when it's indeed all the data 
which allowed in SEQ window has received, but from code, when the packet flaged 
with FIN
no matter whether it's a Out-Of-Order segment or not , no matter whether it's 
data all in the allowed window or not, the stack will treat this FIN as normal 
case and notify the session layer. Something I missed in code ?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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


Re: [vpp-dev] Checking for enabled feature

2019-06-28 Thread Dave Barach via Lists.Fd.Io
Seems like your code is OK, see also vnet_interface_features_show(...) in 
.../src/vnet/feature/feature.c.

We could add per-interface, per-feature arc "feature X is enabled" bitmaps to 
speed up this sort of processing, but there has to be a compelling reason to do 
so.  

What problem are you trying to solve? 

Thanks... Dave 

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Raj
Sent: Friday, June 28, 2019 9:00 AM
To: vpp-dev 
Subject: [vpp-dev] Checking for enabled feature

Hello all,

I am in need to find out whether a particular feature is enabled on an 
interface during run time.

So if I understand correctly we have to get the corresponding 'feature arc 
index '. Then get the config index by using 'config_index_by_sw_if_index' then 
get the config_pool and then iterate through the features list to check whether 
the given feature is there or not.

What I would like to know, is this is the correct approach or is there any 
optimized and a better performing alternative for achieving the same

  current_config_index =
vec_elt (cm[feature_arc].config_index_by_sw_if_index, sw_if_index);
  cfg_index = vcm->config_pool_index_by_user_index[current_config_index];
  cfg = pool_elt_at_index (vcm->config_pool, cfg_index);

  for (i = 0; i < vec_len (cfg->features); i++)
{
  feat = cfg->features + i;
  node_index = feat->node_index;
  n = vlib_get_node (vm, node_index);
   if (0 == memcmp (n->name, input_feat,
sizeof("ip4-policer-classify") - 1))
 return 1;
}

Thanks and Regards,

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

View/Reply Online (#13395): https://lists.fd.io/g/vpp-dev/message/13395
Mute This Topic: https://lists.fd.io/mt/32241517/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] Checking for enabled feature

2019-06-28 Thread Neale Ranns via Lists.Fd.Io

Hi Raj,

There's no good way to do it, there's also no notification should the feature 
be disabled or enabled.
Instead I'd suggest you 'listen' to the entity enabling/disabling the feature.
Or maybe you can configure your feature to run before this one, then it's not 
important whether it's enable or not.

Regards,
neale

-Message d'origine-
De :  au nom de Raj 
Date : vendredi 28 juin 2019 à 15:01
À : vpp-dev 
Objet : [vpp-dev] Checking for enabled feature

Hello all,

I am in need to find out whether a particular feature is enabled on an
interface during run time.

So if I understand correctly we have to get the corresponding 'feature
arc index '. Then get the config index by using
'config_index_by_sw_if_index' then get the config_pool and then
iterate through the features list to check whether the given feature
is there or not.

What I would like to know, is this is the correct approach or is there
any optimized and a better performing alternative for achieving the
same

  current_config_index =
vec_elt (cm[feature_arc].config_index_by_sw_if_index, sw_if_index);
  cfg_index = vcm->config_pool_index_by_user_index[current_config_index];
  cfg = pool_elt_at_index (vcm->config_pool, cfg_index);

  for (i = 0; i < vec_len (cfg->features); i++)
{
  feat = cfg->features + i;
  node_index = feat->node_index;
  n = vlib_get_node (vm, node_index);
   if (0 == memcmp (n->name, input_feat,
sizeof("ip4-policer-classify") - 1))
 return 1;
}

Thanks and Regards,

Raj


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

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


[vpp-dev] A question about TCP statck in version 19.04, when passive FIN coming in first, then APP close with TX fifo not empty, it seem can't have chance to send FIN out. #vnet

2019-06-28 Thread guangwei
Now, I'am searching the TCP stack of VPP 19.04, and have a doubt, please look 
following comment in line.

tcp46_rcv_process_inline
{
...
/* 5: check the ACK field  */
...
case TCP_STATE_CLOSE_WAIT:
/* Do the same processing as for the ESTABLISHED state. */
if (tcp_rcv_ack (wrk, tc0, b0, tcp0, ))
goto drop;

if (!(tc0->flags & TCP_CONN_FINPNDG))
break;

/* Still have outstanding tx data */
if (transport_max_tx_dequeue (>connection))    

[vpp-dev] Checking for enabled feature

2019-06-28 Thread Raj
Hello all,

I am in need to find out whether a particular feature is enabled on an
interface during run time.

So if I understand correctly we have to get the corresponding 'feature
arc index '. Then get the config index by using
'config_index_by_sw_if_index' then get the config_pool and then
iterate through the features list to check whether the given feature
is there or not.

What I would like to know, is this is the correct approach or is there
any optimized and a better performing alternative for achieving the
same

  current_config_index =
vec_elt (cm[feature_arc].config_index_by_sw_if_index, sw_if_index);
  cfg_index = vcm->config_pool_index_by_user_index[current_config_index];
  cfg = pool_elt_at_index (vcm->config_pool, cfg_index);

  for (i = 0; i < vec_len (cfg->features); i++)
{
  feat = cfg->features + i;
  node_index = feat->node_index;
  n = vlib_get_node (vm, node_index);
   if (0 == memcmp (n->name, input_feat,
sizeof("ip4-policer-classify") - 1))
 return 1;
}

Thanks and Regards,

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

View/Reply Online (#13392): https://lists.fd.io/g/vpp-dev/message/13392
Mute This Topic: https://lists.fd.io/mt/32241517/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] #vpp loadbalancer #vpp

2019-06-28 Thread Pierre Pfister (ppfister) via Lists.Fd.Io
Hello,

The VPP LB is pretty much an implementation of Maglev 
(https://ai.google/research/pubs/pub44824).

Maglev is the consistent hashing algorithm used to generate the 
’new_flow_table’.
That table is used when a packet for a flow that is not known by the LB is 
forwarded.
When that happens, the flow is added to the sticky_ht (sticky hash table), such 
that later packets from the same flow go to the same application server (AS).

This consistent-hashing approach is the key to having the ability to have 
multiple LBs running in parallel, without need for synchronization.

VPP LB then supports multiple encaps, like IPv4-GRE or IPv6-GRE for IPv4 or 
IPv6 data packet, NAT for IPv4 or IPv6 or L3DSR for IPv4 (see lb_vip_type_t 
enum).

Cheers,

- Pierre


> Le 26 juin 2019 à 10:46, yangjialu...@gmail.com a écrit :
> 
> Hi guys! Does anyone know about how the sticky_ht, buckets and the 
> new_flow_table work?<屏幕快ç…> § 2019-06-26 16.35.44.png><屏幕快ç…> § 
> 2019-06-26 16.35.12.png> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13377): https://lists.fd.io/g/vpp-dev/message/13377
> Mute This Topic: https://lists.fd.io/mt/32212960/675306
> Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480735
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [ppfis...@cisco.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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