Quick update on where I am with this:
Chris Luke wrote (on Tue 24 Dec, 2013 at 04:46 GMT):
Jesse Gross wrote (on Tue 24 Dec, 2013 at 03:05 GMT):
On Mon, Dec 23, 2013 at 12:13 AM, Chris Luke <chr...@flirble.org> wrote:
[...]
* I agree that upcalls shouldn't work with this model - this seems
like it could be issue to making it work seamlessly.
What suprised me is that I expected the first packet in a flow to
fail. The kernel datapath hands it to userspace and forgets about it.
Userspace does it's thing then programs a flow intp the DP and tries
to send the packet. I expected this packet to get lost in the
bitbucket, but instead I see it responding as though 'normal' Linux
processing *did* happen.
I had ancitipated needing to do something to proactively program
flows into the datapath for this 'normal' action so it catches the
first packet. It may be I am seeing something else and this may yet
be required.
I think I was mistaken about seeing the first packet work - but I have
a method that does. I've added a new method to the vport handler
called 'insert' and it uses 'netif_rx' to re-receive the packet. This
is slightly kludgy because it means, for instance, tcpdump will see
the first packet of such a flow twice. I'm also setting the pkt_type
to loopback so that the hook always ignores it, preventing loops. It
seems the bpf interface also ignores loopback packets, thus
ameliorating the kludge a bit.
I do see quite a delay (1s!) on the initial packet. I may try
netif_rx_ni which will trigger a softirq to go check the input queue
immediately.
But, the ping test works:
from an adjacent VM:
$ ping -n 192.168.128.1
PING 192.168.128.1 (192.168.128.1) 56(84) bytes of data.
64 bytes from 192.168.128.1: icmp_req=1 ttl=64 time=1039 ms
64 bytes from 192.168.128.1: icmp_req=2 ttl=64 time=32.7 ms
64 bytes from 192.168.128.1: icmp_req=3 ttl=64 time=21.3 ms
64 bytes from 192.168.128.1: icmp_req=4 ttl=64 time=21.3 ms
and on the modified ovs box:
14:59:11.461762 ARP, Request who-has 192.168.128.1 tell 192.168.128.2, length 28
14:59:12.458436 ARP, Request who-has 192.168.128.1 tell 192.168.128.2, length 28
14:59:12.458494 ARP, Reply 192.168.128.1 is-at 0e:83:4d:af:21:80, length 28
14:59:12.479544 IP 192.168.128.2 > 192.168.128.1: ICMP echo request, id 27892,
seq 1, length 64
14:59:12.479605 IP 192.168.128.2 > 192.168.128.1: ICMP echo request, id 27892,
seq 2, length 64
14:59:12.479893 IP 192.168.128.1 > 192.168.128.2: ICMP echo reply, id 27892,
seq 1, length 64
14:59:12.479910 IP 192.168.128.1 > 192.168.128.2: ICMP echo reply, id 27892,
seq 2, length 64
14:59:13.469650 IP 192.168.128.2 > 192.168.128.1: ICMP echo request, id 27892,
seq 3, length 64
14:59:13.469705 IP 192.168.128.1 > 192.168.128.2: ICMP echo reply, id 27892,
seq 3, length 64
14:59:14.471033 IP 192.168.128.2 > 192.168.128.1: ICMP echo request, id 27892,
seq 4, length 64
14:59:14.471085 IP 192.168.128.1 > 192.168.128.2: ICMP echo reply, id 27892,
seq 4, length 64
I've also traced through the skb usage and have eliminated a
redundant clone. I also use OVS_CB(skb) to store the 'return
packet to kernel' flag now, cleaning up a lot of value passing
I was doing.
I'll clean up my patch and post it later.
Cheers,
Chris
--
== chr...@flirble.org
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
