Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master
+1
—
Damjan
>
> On 27.01.2021., at 22:49, Dave Wallace wrote:
>
> Folks,
>
> There are currently 636 open Gerrit Reviews on VPP master [0], the oldest
> being submitted on Jun 13, 2016 [1]!
>
> I would like to propose that the Gerrit Review Auto-Abandon job [2] to reduce
> the size of the queue to a more reasonable length. Benefits include (from
> [3]):
>
> - %< -
> Abandoning old inactive changes has the following advantages:
>
> it signals change authors that changes are considered outdated
>
> it keeps dashboards clean
>
> it reduces the load on the server (for open changes the mergeability flag
> is recomputed whenever a change is merged)
>
> If a change is still wanted it can be restored by clicking on the Restore
> button.
> - %< -
>
> I would like to propose the following configuration [2] for auto-abandon:
>
> changeCleanup.abandonAfter: 30d
> changeCleanup.abandonIfMergeable: default (true)
> changeCleanup.cleanupAccountPatchReview:default (false)
> changeCleanup.abandonMessage: default
> changeCleanup.startTime:Sat 00:00
> changeCleanup.interval: 1 day
>
> If you are opposed to the use of Auto-abandon, please propose an alternative
> method to clean up the backlog of reviews on VPP master and maintain a
> reasonably sized queue.
> If you approve of the concept, please respond with a +1.
> If you approve of the concept but don't like the configuration, please
> respond with your preferred configuration.
>
> Lack of response will be interpreted as approval of the use of auto-abandon
> with the proposed configuration ;)
>
> Thanks,
> -daw-
>
> [0] dwallacelf@daw-server-2:~$ ssh -p 29418 gerrit.fd.io gerrit query
> status:open project:vpp branch:master --format=JSON --no-limit | tail -1
> {"type":"stats","rowCount":636,"runTimeMilliseconds":1467,"moreChanges":false}
> [1] https://gerrit.fd.io/r/c/vpp/+/1529
> [2]
> https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#changeCleanup
> [3]
> https://gerrit-review.googlesource.com/Documentation/user-change-cleanup.html#auto-abandon
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18613): https://lists.fd.io/g/vpp-dev/message/18613
Mute This Topic: https://lists.fd.io/mt/80169540/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] issue with RA suppress
Ole, Sorry I am buried in compiler land to help. However, some thoughts may help. Linux IPv6 ND stack processes all ND messages except the RA in the kernel. The RA runs in user space. I think we could just have DPDK handle all ND messages. Also, by default, any network interface in VPP should disable all RA messaging. If the RA is explicitly configured on the interface, then the interface sends out any RA (unsolicited and solicited). Best wishes, Hemant -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Ole Troan Sent: Wednesday, January 27, 2021 6:02 AM To: Benoit Ganne Cc: ashish.sax...@hsc.com; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] issue with RA suppress It's been on the list to rewrite the IPv6 RA code for a while. There might be a use case for disabling periodic advertisements, while at the same time responding to RS messages. In this case though, the interface is set in host mode (via doing autoconfig) and then it should behave like a host, i.e. neither respond to RS nor send periodic RAs. Best regards, Ole smime.p7s Description: S/MIME cryptographic signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18612): https://lists.fd.io/g/vpp-dev/message/18612 Mute This Topic: https://lists.fd.io/mt/80151031/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [EXTERNAL] [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master
+1
I used to do this manually, in effect, though I’ve been less active the past
while which probably accounts for the growth!
FWIW, I usually performed it on an approximate 60 day nudge and 90 day abandon,
about once a month, schedule. I did similar with JIRA but less frequently. I
felt the warning of impending abandonment important enough to make the effort
to do it, though my recollection suggests that in one case did it actually
result in a proposal being revived.
Chris.
From: vpp-dev@lists.fd.io On Behalf Of Dave Wallace
Sent: Wednesday, January 27, 2021 16:50
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP
master
Folks,
There are currently 636 open Gerrit Reviews on VPP master [0], the oldest being
submitted on Jun 13, 2016 [1]!
I would like to propose that the Gerrit Review Auto-Abandon job [2] to reduce
the size of the queue to a more reasonable length. Benefits include (from [3]):
- %< -
Abandoning old inactive changes has the following advantages:
it signals change authors that changes are considered outdated
it keeps dashboards clean
it reduces the load on the server (for open changes the mergeability flag
is recomputed whenever a change is merged)
If a change is still wanted it can be restored by clicking on the Restore
button.
- %< -
I would like to propose the following configuration [2] for auto-abandon:
changeCleanup.abandonAfter: 30d
changeCleanup.abandonIfMergeable: default (true)
changeCleanup.cleanupAccountPatchReview:default (false)
changeCleanup.abandonMessage: default
changeCleanup.startTime:Sat 00:00
changeCleanup.interval: 1 day
If you are opposed to the use of Auto-abandon, please propose an alternative
method to clean up the backlog of reviews on VPP master and maintain a
reasonably sized queue.
If you approve of the concept, please respond with a +1.
If you approve of the concept but don't like the configuration, please respond
with your preferred configuration.
Lack of response will be interpreted as approval of the use of auto-abandon
with the proposed configuration ;)
Thanks,
-daw-
[0] dwallacelf@daw-server-2:~$ ssh -p 29418 gerrit.fd.io gerrit query
status:open project:vpp branch:master --format=JSON --no-limit | tail -1
{"type":"stats","rowCount":636,"runTimeMilliseconds":1467,"moreChanges":false}
[1]
https://gerrit.fd.io/r/c/vpp/+/1529
[2]
https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#changeCleanup
[3]
https://gerrit-review.googlesource.com/Documentation/user-change-cleanup.html#auto-abandon
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18611): https://lists.fd.io/g/vpp-dev/message/18611
Mute This Topic: https://lists.fd.io/mt/80171630/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] [csit-dev] VPP release 21.01 release is available on packagecloud.io/fdio/release !
Congratulations to all of the contributors to VPP 21.01 for another on-time delivery of the fastest software dataplane on the planet! Thank you Andrew, for your continued efforts in automating the release process and successfully guiding the community through another VPP release cycle. Woot!!! -daw- On 1/27/21 4:07 PM, Andrew Yourtchenko wrote: Hi all, VPP release 21.01 is complete and is available from the usual packagecloud.io/fdio/release location! I have verified using the scripts [0] that the new release installs and runs on the Centos8, Debian 10 (Buster) as well as Ubuntu 18.04 and 20.04. A small remark: if you are installing on Debian or Ubuntu 20.04 in a container, you might need to "export VPP_INSTALL_SKIP_SYSCTL=1" before installation such that it skips calling the sysctl command which will fail. (This was a case with 20.09 release as well, but I did not explicitly mention that and there were a few offline questions) Please let me know if you experience any issues. Thanks a lot to Dave Wallace and Vanessa Valderrama for their help during the release process ! [0] https://github.com/ayourtch/vpp-relops/tree/master/docker-tests --a /* your friendly 21.01 release manager */ -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18610): https://lists.fd.io/g/vpp-dev/message/18610 Mute This Topic: https://lists.fd.io/mt/80169693/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master
Folks,
There are currently 636 open Gerrit Reviews on VPP master [0], the
oldest being submitted on Jun 13, 2016 [1]!
I would like to propose that the Gerrit Review Auto-Abandon job [2] to
reduce the size of the queue to a more reasonable length. Benefits
include (from [3]):
- %< -
Abandoning old inactive changes has the following advantages:
it signals change authors that changes are considered outdated
it keeps dashboards clean
it reduces the load on the server (for open changes the
mergeability flag is recomputed whenever a change is merged)
If a change is still wanted it can be restored by clicking on the
Restore button.
- %< -
I would like to propose the following configuration [2] for auto-abandon:
changeCleanup.abandonAfter: 30d
changeCleanup.abandonIfMergeable: default (true)
changeCleanup.cleanupAccountPatchReview: default (false)
changeCleanup.abandonMessage: default
changeCleanup.startTime: Sat 00:00
changeCleanup.interval: 1 day
If you are opposed to the use of Auto-abandon, please propose an
alternative method to clean up the backlog of reviews on VPP master and
maintain a reasonably sized queue.
If you approve of the concept, please respond with a +1.
If you approve of the concept but don't like the configuration, please
respond with your preferred configuration.
Lack of response will be interpreted as approval of the use of
auto-abandon with the proposed configuration ;)
Thanks,
-daw-
[0] dwallacelf@daw-server-2:~$ ssh -p 29418 gerrit.fd.io gerrit query
status:open project:vpp branch:master --format=JSON --no-limit | tail -1
{"type":"stats","rowCount":636,"runTimeMilliseconds":1467,"moreChanges":false}
[1] https://gerrit.fd.io/r/c/vpp/+/1529
[2]
https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#changeCleanup
[3]
https://gerrit-review.googlesource.com/Documentation/user-change-cleanup.html#auto-abandon
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18609): https://lists.fd.io/g/vpp-dev/message/18609
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] VPP release 21.01 release is available on packagecloud.io/fdio/release !
Hi all, VPP release 21.01 is complete and is available from the usual packagecloud.io/fdio/release location! I have verified using the scripts [0] that the new release installs and runs on the Centos8, Debian 10 (Buster) as well as Ubuntu 18.04 and 20.04. A small remark: if you are installing on Debian or Ubuntu 20.04 in a container, you might need to "export VPP_INSTALL_SKIP_SYSCTL=1" before installation such that it skips calling the sysctl command which will fail. (This was a case with 20.09 release as well, but I did not explicitly mention that and there were a few offline questions) Please let me know if you experience any issues. Thanks a lot to Dave Wallace and Vanessa Valderrama for their help during the release process ! [0] https://github.com/ayourtch/vpp-relops/tree/master/docker-tests --a /* your friendly 21.01 release manager */ -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18608): https://lists.fd.io/g/vpp-dev/message/18608 Mute This Topic: https://lists.fd.io/mt/80168525/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] issue with RA suppress
Cisco IOS supports an optional "all" keyword with ipv6 nd ra-suppress to disable any RA operation. VPP should do the same. Ashish reports the default route is changed on issuing the RA. Is the interface receiving the RA looped back to the interface because only then the default router of the interface changes or VPP has lost its brain for IPv6 ND RA. To catch looped back RA or other ND messages, VPP should implement https://tools.ietf.org/html/rfc7527 (add a nonce to messages) - freeBSD supports RFC7527. Host behavior is specified in https://tools.ietf.org/html/rfc5942. Both the RFC I have listed update RFC 4861. Hemant -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Ole Troan Sent: Wednesday, January 27, 2021 6:02 AM To: Benoit Ganne Cc: ashish.sax...@hsc.com; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] issue with RA suppress It's been on the list to rewrite the IPv6 RA code for a while. There might be a use case for disabling periodic advertisements, while at the same time responding to RS messages. In this case though, the interface is set in host mode (via doing autoconfig) and then it should behave like a host, i.e. neither respond to RS nor send periodic RAs. Best regards, Ole smime.p7s Description: S/MIME cryptographic signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18607): https://lists.fd.io/g/vpp-dev/message/18607 Mute This Topic: https://lists.fd.io/mt/80151031/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] #vppcom #vpp-hoststack
Hi Srini, We do not support tcp keep-alives. If you own the two ends of a communication, it should be relatively easy to implement application level keep-alives. Regards, Florin > On Jan 27, 2021, at 2:14 AM, srinimurth...@gmail.com wrote: > > Hi All, >I'm looking to use TCP keep-alive for my application using VPP > Hoststack(FDIO version:20.05) > However, by looking at vcl/vppcom.c, it seems like TCP keep-alive mechanism > is not supported. > > Is TCP keep-alive mechanism supported in VPP com? > > I also wanted to know if we could enable TCP keep-alive mechanism from > internal application using session layer callbacks. > > Thanks, > Srini > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18606): https://lists.fd.io/g/vpp-dev/message/18606 Mute This Topic: https://lists.fd.io/mt/80153998/21656 Mute #vpp-hoststack:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-hoststack Mute #vppcom:https://lists.fd.io/g/vpp-dev/mutehashtag/vppcom Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vlib: startup multi-arch variant configuration fix for interfaces
I missed that detail. I just submitted revert patch….
> On 27.01.2021., at 14:50, Ole Troan wrote:
>
> Hi Radu,
>
> Looks like your patch:
> https://gerrit.fd.io/r/c/vpp/+/30228
>
> Introduces an unfortunate coupling between VLIB and VNET.
> Can you see if you can find a way to avoid calling into VNET from VLIB?
>
> Best regards,
> Ole
>
> static_always_inline void
> -vlib_update_nr_variant_default (vlib_node_registration_t * nr, u8 * variant)
> +vlib_update_nr_variant_default (vlib_node_fn_registration_t * fnr,
> + u8 * variant)
> {
> - vlib_node_fn_registration_t *fnr = nr->node_fn_registrations;
> vlib_node_fn_registration_t *p_reg = 0;
> vlib_node_fn_registration_t *v_reg = 0;
> u32 tmp;
> @@ -127,6 +128,8 @@ vlib_early_node_config (vlib_main_t * vm,
> unformat_input_t * input)
> {
> clib_error_t *error = 0;
> vlib_node_registration_t *nr, **all;
> + vnet_device_class_t *c;
> + vnet_main_t *vnm = vnet_get_main ();
> unformat_input_t sub_input;
> uword *hash = 0, *p;
> u8 *variant = 0;
> @@ -161,10 +164,20 @@ vlib_early_node_config (vlib_main_t * vm,
> unformat_input_t * input)
> nr = vm->node_main.node_registrations;
> while (nr)
>{
> - vlib_update_nr_variant_default (nr, variant);
> + vlib_update_nr_variant_default (nr->node_fn_registrations,
> + variant);
> nr = nr->next_registration;
>}
>
> + /* also apply it to interfaces */
> + c = vnm->device_class_registrations;
> + while (c)
> + {
> + vlib_update_nr_variant_default (c->tx_fn_registrations,
> + variant);
> + c = c->next_class_registration;
> + }
> +
> vec_free (variant);
>}
>}
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18605): https://lists.fd.io/g/vpp-dev/message/18605
Mute This Topic: https://lists.fd.io/mt/80157105/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] vlib: startup multi-arch variant configuration fix for interfaces
While we're at it, ASan complains about
https://gerrit.fd.io/r/c/vpp/+/30228/3/src/vppinfra/cpu.h#94
And I think it is right, 'r->name' is a NULL-terminated C-string as far as I
can tell, not a vector (hence 'vec_len(r->name)' is wrong).
Shouldn't it be a plain strcmp() instead?
Best
ben
> -Original Message-
> From: vpp-dev@lists.fd.io On Behalf Of Ole Troan
> Sent: mercredi 27 janvier 2021 14:50
> To: Radu Nicolau
> Cc: vpp-dev
> Subject: [vpp-dev] vlib: startup multi-arch variant configuration fix for
> interfaces
>
> Hi Radu,
>
> Looks like your patch:
> https://gerrit.fd.io/r/c/vpp/+/30228
>
> Introduces an unfortunate coupling between VLIB and VNET.
> Can you see if you can find a way to avoid calling into VNET from VLIB?
>
> Best regards,
> Ole
>
> static_always_inline void
> -vlib_update_nr_variant_default (vlib_node_registration_t * nr, u8 *
> variant)
> +vlib_update_nr_variant_default (vlib_node_fn_registration_t * fnr,
> + u8 * variant)
> {
> - vlib_node_fn_registration_t *fnr = nr->node_fn_registrations;
>vlib_node_fn_registration_t *p_reg = 0;
>vlib_node_fn_registration_t *v_reg = 0;
>u32 tmp;
> @@ -127,6 +128,8 @@ vlib_early_node_config (vlib_main_t * vm,
> unformat_input_t * input)
> {
>clib_error_t *error = 0;
>vlib_node_registration_t *nr, **all;
> + vnet_device_class_t *c;
> + vnet_main_t *vnm = vnet_get_main ();
>unformat_input_t sub_input;
>uword *hash = 0, *p;
>u8 *variant = 0;
> @@ -161,10 +164,20 @@ vlib_early_node_config (vlib_main_t * vm,
> unformat_input_t * input)
> nr = vm->node_main.node_registrations;
> while (nr)
> {
> - vlib_update_nr_variant_default (nr, variant);
> + vlib_update_nr_variant_default (nr-
> >node_fn_registrations,
> + variant);
> nr = nr->next_registration;
> }
>
> + /* also apply it to interfaces */
> + c = vnm->device_class_registrations;
> + while (c)
> + {
> + vlib_update_nr_variant_default (c->tx_fn_registrations,
> + variant);
> + c = c->next_class_registration;
> + }
> +
> vec_free (variant);
> }
> }
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18604): https://lists.fd.io/g/vpp-dev/message/18604
Mute This Topic: https://lists.fd.io/mt/80157105/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] vlib: startup multi-arch variant configuration fix for interfaces
Hi Radu,
Looks like your patch:
https://gerrit.fd.io/r/c/vpp/+/30228
Introduces an unfortunate coupling between VLIB and VNET.
Can you see if you can find a way to avoid calling into VNET from VLIB?
Best regards,
Ole
static_always_inline void
-vlib_update_nr_variant_default (vlib_node_registration_t * nr, u8 * variant)
+vlib_update_nr_variant_default (vlib_node_fn_registration_t * fnr,
+ u8 * variant)
{
- vlib_node_fn_registration_t *fnr = nr->node_fn_registrations;
vlib_node_fn_registration_t *p_reg = 0;
vlib_node_fn_registration_t *v_reg = 0;
u32 tmp;
@@ -127,6 +128,8 @@ vlib_early_node_config (vlib_main_t * vm, unformat_input_t
* input)
{
clib_error_t *error = 0;
vlib_node_registration_t *nr, **all;
+ vnet_device_class_t *c;
+ vnet_main_t *vnm = vnet_get_main ();
unformat_input_t sub_input;
uword *hash = 0, *p;
u8 *variant = 0;
@@ -161,10 +164,20 @@ vlib_early_node_config (vlib_main_t * vm,
unformat_input_t * input)
nr = vm->node_main.node_registrations;
while (nr)
{
- vlib_update_nr_variant_default (nr, variant);
+ vlib_update_nr_variant_default (nr->node_fn_registrations,
+ variant);
nr = nr->next_registration;
}
+ /* also apply it to interfaces */
+ c = vnm->device_class_registrations;
+ while (c)
+ {
+ vlib_update_nr_variant_default (c->tx_fn_registrations,
+ variant);
+ c = c->next_class_registration;
+ }
+
vec_free (variant);
}
}
signature.asc
Description: Message signed with OpenPGP
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18603): https://lists.fd.io/g/vpp-dev/message/18603
Mute This Topic: https://lists.fd.io/mt/80157105/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] issue with RA suppress
> Looking at the code, it looks like when RA is tuned off in VPP it stops to > send periodic RA but continues to respond to RS. And this is coherent with > the logs you shared. > I think 'suppress-ra' should turn off both periodic RA and RS reponses if I > read RFC 4861 correctly [1]. > Ole any advice here? > > [1] "AdvSendAdvertisements" variable described in > https://tools.ietf.org/html/rfc4861#section-6.2.1 It's been on the list to rewrite the IPv6 RA code for a while. There might be a use case for disabling periodic advertisements, while at the same time responding to RS messages. In this case though, the interface is set in host mode (via doing autoconfig) and then it should behave like a host, i.e. neither respond to RS nor send periodic RAs. Best regards, Ole signature.asc Description: Message signed with OpenPGP -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18602): https://lists.fd.io/g/vpp-dev/message/18602 Mute This Topic: https://lists.fd.io/mt/80151031/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 crash after enabling address sanitizer
Hi Ben, Thanks for the quick response. I don't see a possibility of this getting called from any other thread. As seen in the ASAN error o/p , its happening in the main_thread only always. WRITE of size 61 at 0x7fffc519aa5f thread T0 ( *vpp_main* ) Any idea what could be happening here. This issue is making the ASAN not useable with VPP. Please share your views on any workarounds for this. -- Thanks & Regards, Murthy -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18601): https://lists.fd.io/g/vpp-dev/message/18601 Mute This Topic: https://lists.fd.io/mt/80099837/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] #vppcom #vpp-hoststack
Hi All, I'm looking to use TCP keep-alive for my application using VPP Hoststack(FDIO version:20.05) However, by looking at vcl/vppcom.c, it seems like TCP keep-alive mechanism is not supported. Is TCP keep-alive mechanism supported in VPP com? I also wanted to know if we could enable TCP keep-alive mechanism from internal application using session layer callbacks. Thanks, Srini -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18600): https://lists.fd.io/g/vpp-dev/message/18600 Mute This Topic: https://lists.fd.io/mt/80153998/21656 Mute #vppcom:https://lists.fd.io/g/vpp-dev/mutehashtag/vppcom Mute #vpp-hoststack:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-hoststack Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] issue with RA suppress
Hi Ashish, Looking at the code, it looks like when RA is tuned off in VPP it stops to send periodic RA but continues to respond to RS. And this is coherent with the logs you shared. I think 'suppress-ra' should turn off both periodic RA and RS reponses if I read RFC 4861 correctly [1]. Ole any advice here? [1] "AdvSendAdvertisements" variable described in https://tools.ietf.org/html/rfc4861#section-6.2.1 ben > -Original Message- > From: vpp-dev@lists.fd.io On Behalf Of > ashish.sax...@hsc.com > Sent: mercredi 27 janvier 2021 06:21 > To: vpp-dev@lists.fd.io > Subject: [vpp-dev] issue with RA suppress > > > Hi All, > We are seeing some issue with VPP sending RA’s on STL interface. We saw > this issue initially when VPP was sending RA, causing the default route > advertised by the router to be removed. To fix that, we added ra-suppress > config on each interface, but that does not seem to be working. > > > > I am using the following configuration: > > create sub-interfaces BondEthernet0 800 > > set int state HundredGigabitEthernet12/0/0 up > > set int state BondEthernet0 up > > set int state BondEthernet0.800 up > > ip6 nd address autoconfig BondEthernet0.800 default-route > > > > ip6 nd BondEthernet0.800 ra-suppress > > > > “show ip6 interface” is still showing RA being sent out: > > BondEthernet0.800 is admin up > > Local unicast address(es): > > fdfd:fd69:90:800:ba83:3ff:fe9e:9891/64 > > fd0d:1:2:cc:a5a5:11f:fe57:a5a5/64 > > fd0d:1:2:cc:a5a5:1f:fe5f:a5a5/64 > > Link-local address(es): > > fe80::ba83:3ff:fe9e:9891 > > Joined group address(es): > > ff02::1 > > ff02::2 > > ff02::16 > > ff02::1:ff9e:9891 > > ff02::1:ff57:a5a5 > > ff02::1:ff5f:a5a5 > > Neighbor Discovery: enabled > > ICMP redirects are disabled > > ICMP unreachables are not sent > > ND DAD is disabled > > Advertised Prefixes: > > MTU is 9000 > > ICMP error messages are unlimited > > ICMP redirects are disabled > > ICMP unreachables are not sent > > ND DAD is disabled > > ND advertised reachable time is 0 > > ND advertised retransmit interval is 0 (msec) > > ND router advertisements are sent every 200.0 seconds (min interval is > 150.0) > > ND router advertisements live for 600 seconds > > Hosts don't use stateless autoconfig for addresses > > ND router advertisements sent 8 > > ND router solicitations received 8 > > ND router solicitations dropped 0 > > > > I could not find anything in the log and “ra-suppress” command is not > returning any error. Is there any issue with this command ? > What can we do to fix the problem? > > Thanks and regards, > Ashish > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18599): https://lists.fd.io/g/vpp-dev/message/18599 Mute This Topic: https://lists.fd.io/mt/80151031/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
