Re: [GIT net-next] Open vSwitch

On Mon, Jan 13, 2014 at 4:31 PM, Zoltan Kiss [off-list ref] wrote:

On 13/01/14 18:04, Zoltan Kiss wrote:

quoted

On 08/01/14 15:10, Jesse Gross wrote:

quoted

On Wed, Jan 8, 2014 at 9:49 AM, Zoltan Kiss [off-list ref]
wrote:

quoted

Hi,

I've tried the latest net-next on a Xenserver install with 1.9.3
userspace,
and it seems this patch series broke it (at least after reverting that
locally it works now). I haven't went too far yet checking what's the
problem, but it seems the xenbrX device doesn't really receive too much
of
the traffic coming through the NIC. Is it expected?

What do you mean by doesn't receive too much traffic? What does it get?

Sorry for the vague error description, now I had more time to look into
this. I think the problem boils down to this:

Jan 13 17:55:07 localhost ovs-vswitchd:
07890|netlink_socket|DBG|nl_sock_recv__ (Success): nl(len:274,
type=29(ovs_packet), flags=0, seq=0, pid=0,genl(cmd=1,version=1)
Jan 13 17:55:07 localhost ovs-vswitchd: 07891|netlink|DBG|attributes
followed by garbage
Jan 13 17:55:07 localhost ovs-vswitchd: 07892|dpif|WARN|system@xenbr0:
recv failed (Invalid argument)

That's just keep repeating. I'm keep looking.

Now I reverted these top 3 commits:

ovs: make functions local

openvswitch: Compute checksum in skb_gso_segment() if needed
openvswitch: Use skb_zerocopy() for upcall

And it works. I guess the last one causing the problem. Might be an
important factor, I'm using 32 bit Dom0.

I think you're probably right. Thomas - can you take a look?

We shouldn't be doing any zerocopy in this situation but it looks to
me like we don't do any padding at all, even in situations where we
are copying the data.