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
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
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
>
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
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
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
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
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.
+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
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]):
- %<
+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
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
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
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
> 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
15 matches
Mail list logo
