[ovs-dev] Possible user-space datapath regression

[Justin Pettit]

Sorry for the delay.  Here's a patch I just sent out that I think addresses the issue:

    http://openvswitch.org/pipermail/dev/2012-December/023652.html

Let me know if it works or if you still see problems.  Thanks!

--Justin


On Nov 28, 2012, at 4:06 PM, Simon Horman <horms at verge.net.au> wrote:

> Thanks, let me know if you need any more information from me.
> 
> On Tue, Nov 27, 2012 at 10:31:17PM -0600, Justin Pettit wrote:
>> Hi, Simon.  I've confirmed the problem you found and am looking into it.  Unfortunately, I'm traveling this week for work, so I may have limited time to look at it until Friday.
>> 
>> Thanks for the report.
>> 
>> --Justin
>> 
>> 
>> On Nov 20, 2012, at 2:44 AM, Simon Horman <horms at verge.net.au> wrote:
>> 
>>> Hi,
>>> 
>>> I believe I have found a regression that affects the behaviour of the
>>> datapath. A quick bisection points to the following patch:
>>> 
>>> 	acf60855126bcfa79ea22d7846af5f2efe26cd30
>>> 	ofproto-dpif: Use a single underlying datapath across multiple bridges.
>>> 
>>> 
>>> For my test I run Open vSwtich inside a kvm VM. Inside the VM
>>> there are two ethernet interfaces, eth0 and eth1 although only
>>> eth1 is used in this test. The interfaces are emulated and
>>> the other end of eth1 is tap1 in the host.
>>> 
>>> eth1 has been added to an Open vSwtich bridge in the VM.
>>> The output of ovs-vsctl show is as follows:
>>> 
>>> cff268ec-4e3d-41fa-8127-efa2bb851ae7
>>>   Bridge "br0"
>>>       Port "eth1"
>>>           Interface "eth1"
>>>       Port "br0"
>>>           Interface "br0"
>>>               type: internal
>>>   ovs_version: "1.9.90"
>>> 
>>> When I try to from the host to the VM I obvserve that the VM
>>> does not respond to ARP requests.
>>> 
>>> COnversely, when I try to ping from the VM to the host it appears
>>> that the VM ignores ARP responses.
>>> 
>>> If I checkout acf60855126bcfa79ea22d7846af5f2efe26cd30^ then all seems well.
>>> If I checkout acf60855126bcfa79ea22d7846af5f2efe26cd30 I get the behaviour
>>> that I have described above.
>>> 
>>> I have not debuged the problem any further yet.
>>> 
>>