Looks like there are some CI failures in unrelated test cases ... https://jenkins.fd.io/job/vpp-debug-verify-master-ubuntu2004-x86_64/696/console
On Sat, Jan 16, 2021 at 3:58 AM Florin Coras <fcoras.li...@gmail.com> wrote: > Thanks! > > Cheers, > Florin > > On Jan 15, 2021, at 4:49 PM, Ivan Shvedunov <ivan...@gmail.com> wrote: > > https://gerrit.fd.io/r/c/vpp/+/30791 > > On Sat, Jan 16, 2021 at 3:22 AM Florin Coras <fcoras.li...@gmail.com> > wrote: > >> Hi Ivan, >> >> You’re right that the assert wrongly assumes the connection must’ve been >> established. I’m guessing you’re only sporadically hitting it because >> typically the peer should not retransmit the syn after our reset (but >> probably the packet is lost). Want to push a patch to remove it or should >> I do it? >> >> Regards, >> Florin >> >> On Jan 15, 2021, at 3:57 PM, Ivan Shvedunov <ivan...@gmail.com> wrote: >> >> Hi, >> in our UPG project[1] I'm sometimes hitting the following assertion in >> tcp[46]-syn-sent when trying to use at least 1 worker thread: >> >> https://github.com/FDio/vpp/blob/35ef865678d82b5a6fd3936716de8afb2fd49e60/src/vnet/tcp/tcp_input.c#L1820-L1821 >> We're using the host stack in a rather non-standard way, so chances are >> that this assertion is valid, but so far I didn't manage to understand why. >> Problem is that half-open connection cleanup may happen after an >> unsuccessful connect notify callback: >> >> https://github.com/FDio/vpp/blob/35ef865678d82b5a6fd3936716de8afb2fd49e60/src/vnet/tcp/tcp_input.c#L1955-L1962 >> >> https://github.com/FDio/vpp/blob/35ef865678d82b5a6fd3936716de8afb2fd49e60/src/vnet/tcp/tcp_input.c#L1978-L1986 >> which leads us here: >> >> https://github.com/FDio/vpp/blob/35ef865678d82b5a6fd3936716de8afb2fd49e60/src/vnet/tcp/tcp_input.c#L2016-L2021 >> In this case, if the half-open connection belongs to another thread (and >> it usually belongs to the main thread), the actual cleanup is delayed >> and TCP_CONN_HALF_OPEN_DONE flag is set for the connection, but, due to the >> notify call failure, the connection establishment is not completed so the >> assertion mentioned above can't be satisfied. >> Am I missing a reason why the buffer should actually never reach >> tcp[46]-syn-sent node after the corresponding half-open connection is >> undergoing this delayed cleanup, so perhaps UPG TCP proxy code needs to be >> corrected there, or is this ASSERT indeed invalid? >> >> [1] https://github.com/travelping/upg-vpp >> >> >> >> > > -- > Ivan Shvedunov <ivan...@gmail.com> > ;; My GPG fingerprint is: 2E61 0748 8E12 BB1A 5AB9 F7D0 613E C0F8 0BC5 > 2807 > > > -- Ivan Shvedunov <ivan...@gmail.com> ;; My GPG fingerprint is: 2E61 0748 8E12 BB1A 5AB9 F7D0 613E C0F8 0BC5 2807
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18526): https://lists.fd.io/g/vpp-dev/message/18526 Mute This Topic: https://lists.fd.io/mt/79717445/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
