Date: Wed, 22 Oct 2014 14:32:37 -0700 From: "K. Macy" <kmacy@freebsd.org> To: "De La Gueronniere, Marc" <mdelagueronniere@verisign.com> Cc: Ryan Stone <rysto32@gmail.com>, Oleg Bulyzhin <oleg@freebsd.org>, "Charbon, Julien" <jcharbon@verisign.com>, freebsd-net <freebsd-net@freebsd.org> Subject: Re: buf_ring in HEAD is racy Message-ID: <CAHM0Q_MMn4j2G%2BM2XdLw56A9BAsdKsLKD91Dm2%2B6Y=mpt%2BxsJQ@mail.gmail.com> In-Reply-To: <D06D9912.1507F%mdelagueronniere@verisign.com> References: <CAFMmRNyJpvZ0AewWr62w16=qKer%2BFNXUJJy0Qc=EBqMnUV3OyQ@mail.gmail.com> <20131226175410.GA15332@lath.rinet.ru> <D06D9912.1507F%mdelagueronniere@verisign.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi Oleg and Ryan, > > We have run into the spurious drop issue too. I could not make sense of > seeing a single drop at a time every few seconds i.e. if a queue of 4k > element fills, likely more than one packet is going to be dropped once th= e > queue full condition is reached. So we investigated and came to the same > conclusion on buf_ring_enqueue being broken, at which point I found this > thread. > > Are there any pending patches/investigations beside Oleg=C2=B9s patch ? W= e are > definitely interested in helping with this, I just want to make sure that > we are not duplicating efforts. > > I also suspect there are further problems with buf_ring. A full wrap > around of the atomically swapped value is possible. I.e. the code thinks > it just atomically updated a head/tail index when in fact a full wrap > around occurred leading to undefined land. A relatively simple way to > avoid this is to only mask on ring array access, and to let the > head/tail/prod/cons indices overflow the array. I'll have 40GigE hardware to test with in a week or two. I'll look in to it then. Cheers. -K
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHM0Q_MMn4j2G%2BM2XdLw56A9BAsdKsLKD91Dm2%2B6Y=mpt%2BxsJQ>