Hi,

On Tue, Jan 25, 2005 at 11:47:11PM +0100, Gert Doering wrote:
> There is one problem remaining: for IPv6-over-GRE packets, there is a
> weird delay upon reception.  It's like schednetisr() isn't called,
> except that the delay always seems to be about 300-1200 ms, while without
> schednetisr(), it's indefinite (that is: until another interface receives
> an IPv6 packet, to be precise).

Actually, this is NOT a problem of my IPv6-over-GRE patches.

After comparing the gif/gre sources for a number of hours, to see whether
GRE does something differently than GIF, I decided to actually test it
with GIF.  The problem is the same!  (Sparc64, NetBSD-current as of Jan 27).

Here's is the setup on the NetBSD side:

ifconfig gif0 create
ifconfig gif0 tunnel 193.149.48.168 195.30.70.42
ifconfig gif0 10.58.58.2 10.58.58.1 netmask 255.255.255.0 link0 up
ifconfig gif0 inet6 2001:608:4:5555::2/64
route add -inet6 2001:608:4:5555::/64 2001:608:4:5555::1
route change -inet6 2001:608:4:5555::/64 -ifp gif0

And this is the Cisco side:

interface Tunnel11
 ip address 10.58.58.1 255.255.255.0
 ipv6 address 2001:608:4:5555::1/64
 tunnel source 195.30.70.42
 tunnel destination 193.149.48.168
 tunnel mode ipv6ip
end

This happens when I run a ping on the Cisco side:

cisco2514#ping 2001:608:4:5555::2 repeat 2

Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 2001:608:4:5555::2, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 264/358/452 ms

(these machines are connected over *LAN*, so RTTs over 200ms are plain
impossible under normal circumstances)

This is the tcpdump output on the NetBSD side, taken on the LAN interface
("tcpdump -i hme0 -v -s0 -n host 195.30.70.42"):

20:58:43.153611 195.30.70.42 > 193.149.48.168: 2001:608:4:5555::1 > 2001:608:4:5555::2: icmp6: echo request (len 60, hlim 64) (ttl 255, id 23, len 120)
20:58:43.412376 193.149.48.168 > 195.30.70.42: 2001:608:4:5555::2 > 2001:608:4:5555::1: icmp6: echo reply (len 60, hlim 64) (ttl 30, id 480, len 120)
20:58:43.424927 195.30.70.42 > 193.149.48.168: 2001:608:4:5555::1 > 2001:608:4:5555::2: icmp6: echo request (len 60, hlim 64) (ttl 255, id 24, len 120)
20:58:43.873478 193.149.48.168 > 195.30.70.42: 2001:608:4:5555::2 > 2001:608:4:5555::1: icmp6: echo reply (len 60, hlim 64) (ttl 30, id 481, len 120)

as you can see from the time stamps, the (encapsulated) ICMPv6 echo request
is received on the LAN, and it takes full 250ms to send back the 
(encapsulated) IPv6 echo reply packet.  This is the same packet scheduling
weirdness that I've seen with my IPv6-over-GRE tests, and I read it as
something more fundamental in the way the different protocol queues are
handled.


For completeness, I've run the same tests while at the same time running
"ping6 -i 0.02 $netbsd-machine" from another host on the LAN, and this
is the result:

cisco2514#ping 2001:608:4:5555::2 repeat 2

Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 2001:608:4:5555::2, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 12/14/16 ms

21:07:04.630021 195.30.70.42 > 193.149.48.168: 2001:608:4:5555::1 > 2001:608:4:5555::2: icmp6: echo request (len 60, hlim 64) (ttl 255, id 25, len 120)
21:07:04.639910 193.149.48.168 > 195.30.70.42: 2001:608:4:5555::2 > 2001:608:4:5555::1: icmp6: echo reply (len 60, hlim 64) (ttl 30, id 495, len 120)
21:07:04.653535 195.30.70.42 > 193.149.48.168: 2001:608:4:5555::1 > 2001:608:4:5555::2: icmp6: echo request (len 60, hlim 64) (ttl 255, id 26, len 120)
21:07:04.659880 193.149.48.168 > 195.30.70.42: 2001:608:4:5555::2 > 2001:608:4:5555::1: icmp6: echo reply (len 60, hlim 64) (ttl 30, id 496, len 120)

-> the delay times are much lower, if there are other IPv6 packets being
processed anyway (as in my GRE tests, see previous e-mail).

As I have *no* idea how the lower-level packet scheduling stuff works,
I need your help here - OTOH I think this is something that someone 
should care about, as it doesn't only affect "my" pet project :-)
(I can open a PR if that helps - just tell me).

Running any sort of specific test with specific packets, background
pings, kernel patches, whatnot, is not a problem - this machine isn't 
doing anything productive, so I can wreck it any day...

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-35655025                        gert@net.informatik.tu-muenchen.de