> 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 the > 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¹s patch ? We 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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
