[ovs-dev] [PATCH 2/2] ofproto: Avoid buffer copy in OFPT_PACKET_IN path.

[Jean Tourrilhes]

	Hi,

	Merging two e-mail thread for expediency...

On Tue, Apr 27, 2010 at 11:14:45AM -0700, Martin Casado wrote:
>
>> 	Stanford is starting to test my 1.0 firmware based on OVS. We
>> have already identified an issue between NoX and my
>> firmware. I suspect nobody bothered to check NoX against Open vSwitch,
>> because I believe the bug would also apply to OVS.
>>   
>
> Hi Jean,
>
> We routinely run OVS against NoX.  We would be interested in knowing  
> what the problem is once you've rooted out the culprit.
>
> .martin

	I've reproduced the problem this morning with a one month old
master of Open vSwitch on a PC with a yesterday master of NoX, using
the routing module. The basic ping just hangs. Maybe I should get
a newer version of Open vSwitch.

On Tue, Apr 27, 2010 at 11:10:19AM -0700, Paul Weissmann wrote:
> 
> We quickly looked into it yesterday but wanted to debug this again tomorrow.
> The guy working on the NOX 1.0 implementation said that nw_proto handling
> in NOX should be fine though (the ARP opcodes).

	Well, then tell me where I'm wrong.

	This is the ofctl dump of the Open vSwitch after I tried to
ping.
------------------------------------------------------
>./ovs-ofctl dump-flows tcp:127.0.0.1:6634
stats_reply (xid=0x352901a1): flags=none type=1(flow)
  cookie=14534643445914646623, duration_sec=0s, duration_nsec=835000000ns, table_id=0, priority=65535, n_packets=0, n_bytes=0, idle_timeout=5,arp,in_port=2,dl_vlan=0xffff,dl_vlan_pcp=0,dl_src=00:60:b0:ce:2d:d9,dl_dst=08:00:09:fe:ed:bd,nw_src=15.144.110.9,nw_dst=15.144.110.2,opcode=1,icmp_type=0,icmp_code=0,actions=output:1
  cookie=14132176974031086214, duration_sec=3s, duration_nsec=845000000ns, table_id=0, priority=65535, n_packets=3, n_bytes=294, idle_timeout=5,icmp,in_port=2,dl_vlan=0xffff,dl_vlan_pcp=0,dl_src=00:60:b0:ce:2d:d9,dl_dst=08:00:09:fe:ed:bd,nw_src=15.144.110.9,nw_dst=15.144.110.2,icmp_type=8,icmp_code=0,actions=output:1
  cookie=17160831227759726843, duration_sec=3s, duration_nsec=843000000ns, table_id=0, priority=65535, n_packets=4, n_bytes=240, idle_timeout=60,arp,in_port=1,dl_vlan=0xffff,dl_vlan_pcp=0,dl_src=08:00:09:fe:ed:bd,dl_dst=ff:ff:ff:ff:ff:ff,nw_src=15.144.110.2,nw_dst=15.144.110.9,opcode=1,icmp_type=0,icmp_code=0,actions=FLOOD
------------------------------------------------------

	The thing to look is the "opcode" for the ARP reply. It is
'1', and by my quick reading of the ARP protocol, it should be
'2'. I get similar result on the ProCurve.

http://en.wikipedia.org/wiki/Address_Resolution_Protocol#Packet_structure

	I've attached the pcap trace of the ping. If you run it
through the openflow wireshark plugin, you can see that the ARP reply
in the packet_in comes with an opcode of '2', and the flow_mod in the
match has an opcode of '1'.

	Note that the default behaviour of a OFPP_TABLE miss may hide
this bug.

	Regards,

	Jean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nox-arp-opcode-extract.pcap
Type: application/cap
Size: 1322 bytes
Desc: not available
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20100427/f10cacc0/attachment-0003.bin>