On Mon, May 29, 2017 at 06:57 +0200, Sebastien Marie wrote:
> On Sun, May 28, 2017 at 10:45:34PM +0200, Mike Belopuhov wrote:
> > > 
> > > mikeb@, I don't reproduce if I backout the local diff.
> > > 
> > > it seems bce(4) doesn't like it.
> > 
> > Indeed, a lot of things won't like this since xxx_start may be called
> > directly by the driver.  To handle this situation we need to make sure
> > that IFQ_DEQUEUE that is called by these xxx_start routines provides a
> > compatible interface.  Please try the diff below.  If this solves your
> > issue, I'd like to get it in w/o assertions unless there are objections.
> 
> 
> with or without codel queue: the remote connection seems really *slow*.
>

This is an interesting artifact.  Thanks for noticing, I'm curious what's
causing it.

> bert (patched) and clyde (unpatched) hsots are connected on same LAN
> segment.
> 
> clyde:~$ ping6 bert
> PING bert (2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a): 56 data bytes
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=0 hlim=64 
> time=1002.655 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=1 hlim=64 
> time=0.763 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=2 hlim=64 
> time=1000.330 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=3 hlim=64 
> time=1000.388 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=4 hlim=64 
> time=1000.396 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=5 hlim=64 
> time=1000.373 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=6 hlim=64 
> time=0.432 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=7 hlim=64 
> time=1000.349 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=8 hlim=64 
> time=0.480 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=9 hlim=64 
> time=228.896 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=10 hlim=64 
> time=20.386 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=11 hlim=64 
> time=0.504 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=12 hlim=64 
> time=0.582 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=13 hlim=64 
> time=864.730 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=14 hlim=64 
> time=1000.343 ms
> ^C
> --- bert ping statistics ---
> 16 packets transmitted, 15 packets received, 6.2% packet loss
> round-trip min/avg/max/std-dev = 0.432/541.440/1002.655/476.996 ms
> 
> 
> 
> Surprising thing (for me): having tcpbench running in background between
> the two hosts reduces the lag (but still high on a LAN).
> 
> clyde:~$ ping6 bert
> PING bert (2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a): 56 data bytes
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=0 hlim=64 
> time=1.393 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=1 hlim=64 
> time=19.961 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=2 hlim=64 
> time=23.404 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=3 hlim=64 
> time=26.457 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=4 hlim=64 
> time=29.159 ms
> 64 bytes from 2001:41d0:fe39:c05c:215:c5ff:fe0b:8b7a: icmp_seq=5 hlim=64 
> time=30.862 ms
> ^C
> --- bert ping statistics ---
> 6 packets transmitted, 6 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 1.393/21.873/30.862/9.835 ms
> 
>

Thanks for taking your time to test, but unfortunately I have to
withdraw both diffs.  I've realised that there's a ton of drivers
calling ifq_deq_begin manually from their start routines and
there's no simple solution for that that I can find right now.

I'll try to come up with something that works for all cases ASAP.

Reply via email to