On 15/04/13 18:15, Ben Pfaff wrote:
On Mon, Apr 15, 2013 at 03:59:52PM +0100, Zoltan Kiss wrote:
When the packet is sent to the controller due to an userspace rule (and not
a kernel-space flow), execute_controller_action is invoked with clone=true,
so handle_flow_miss retains ownership of the packet buffer. But if it returns
true (which means the packet had only a PACKET_IN action), nothing frees up
the buffer.
I think you're right. But in that case, wouldn't it solve the problem
in a better way (doing less memory allocation and copying) by passing
clone=false, instead of passing clone=true and then freeing the packet
in the caller?
It sounds reasonable, and I was thinking about that, but I was worried
about the side-effects. Now I've tried it, and it seems it cause
problems indeed. Broadcast ARP packets are causing problem here:
dpif|WARN|Dropped 26 log messages in last 1 seconds (most recently, 1
seconds ago) due to excessive rate
dpif|WARN|system@xenbr0: failed to flow_del (No such file or directory)
in_port(1),eth(src=ab:cd:ef:12:34:56,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=10.0.0.1,tip=10.0.0.2,op=1,sha=ab:cd:ef:12:34:56,tha=00:00:00:00:00:00)
These messages are coming continuously if I install that joker rule to
userspace. And it doesn't happen with the original clone=true version. I
haven't found out yet why this happens, it shouldn't really change
anything but the time when the packet is freed.
Regards,
Zoli
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
