The vpp-debug-verify-master-ubuntu2004 job is non voting, but one of the csit jobs is and it apparently failed. There are no tcp tests there so let’s see if the recheck passes.
Regards, Florin > On Jan 16, 2021, at 3:28 AM, Ivan Shvedunov <ivan...@gmail.com> wrote: > > 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 > > <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 > <mailto:fcoras.li...@gmail.com>> wrote: > Thanks! > > Cheers, > Florin > >> On Jan 15, 2021, at 4:49 PM, Ivan Shvedunov <ivan...@gmail.com >> <mailto:ivan...@gmail.com>> wrote: >> >> https://gerrit.fd.io/r/c/vpp/+/30791 <https://gerrit.fd.io/r/c/vpp/+/30791> >> >> On Sat, Jan 16, 2021 at 3:22 AM Florin Coras <fcoras.li...@gmail.com >> <mailto: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 >>> <mailto: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 >>> >>> <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#L1955-L1962> >>> https://github.com/FDio/vpp/blob/35ef865678d82b5a6fd3936716de8afb2fd49e60/src/vnet/tcp/tcp_input.c#L1978-L1986 >>> >>> <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 >>> >>> <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 >>> <https://github.com/travelping/upg-vpp> >>> >>> >> >> >> >> -- >> Ivan Shvedunov <ivan...@gmail.com <mailto:ivan...@gmail.com>> >> ;; My GPG fingerprint is: 2E61 0748 8E12 BB1A 5AB9 F7D0 613E C0F8 0BC5 2807 > > > > -- > Ivan Shvedunov <ivan...@gmail.com <mailto: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 (#18528): https://lists.fd.io/g/vpp-dev/message/18528 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] -=-=-=-=-=-=-=-=-=-=-=-
