Just use this patch and the connection can be reconnected after closed.
However, I find another possible bug when using local ip + local port for
different target server due to transport_endpoint_mark_used return error
if it find local ip + port being created.
I think it should increase the refcn
Hi all,
I found that bihash might return zero'ed value (0xff's) if deletion and
searching were performed in parallel on different threads. This is reproducible
by only ~100 lines of code, from 21.06 all the way up to git master, and on
multiple machines from Coffee Lake to Tiger Lake.
The code
Hi all,
I’ve prepared the 23.06 release plan - and linked it off the usual place on VPP
wiki:
https://wiki.fd.io/view/VPP#Get_Involved
Tl;dr: release the last Wednesday of June, RC2 two weeks prior; RC1 three weeks
prior to RC2. Looks like this schedule works well. Same logic as usual -
post-
Quick experiment: in
src/vppinfra/bihash_template.h:clib_bihash_search_inline_2_with_hash(),
replace this:
if (PREDICT_FALSE (b->lock))
{
volatile BVT (clib_bihash_bucket) * bv = b;
while (bv->lock)
CLIB_PAUSE ();
}
With:
BV(clib_bihash_lock_bucket(b));
and make su
Hi,
Are you looking for behavior similar to the one when random local ports are
allocated when, if port is used, we check if the 5-tuple is available?
Don’t think we explicitly supported this before but here’s a patch [1].
Regards,
Florin
[1] https://gerrit.fd.io/r/c/vpp/+/38486
> On Mar
Sali Pim
I just found the solution.
set interface unnumbered GigabitEthernet3/0/0 use tap2
This in combination with RequestBroadcast worked and I've got an IP on
Linux.
Thank you for your help, for your work on lcpng and for your articles on
ipng.ch they are very interesting and helpful.
Hi,
I've done the change you asked, and the "suspicious value" warnings are all
gone. Here is the diff:
diff --git a/src/vppinfra/bihash_template.h b/src/vppinfra/bihash_template.h
index c4e120e4a..b9f658db3 100644
--- a/src/vppinfra/bihash_template.h
+++ b/src/vppinfra/bihash_template.h
@@ -532
