* Re: [Qemu-devel] [dpdk-dev] [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
@ 2017-11-27 14:27 ` Yuanhan Liu
0 siblings, 0 replies; 14+ messages in thread
From: Yuanhan Liu @ 2017-11-27 14:27 UTC (permalink / raw)
To: Chen Hailin
Cc: Aaron Conole, jianfeng.tan, ovs-dev@openvswitch.org,
Maxime Coquelin, cloud, qemu-devel, dev
On Fri, Nov 24, 2017 at 05:59:09PM +0800, Chen Hailin wrote:
> Hi Aaron Conole && Jianfeng,
>
> The stp could not work in ovs-dpdk vhostuser.
> Because the attached vhost device doesn't have MAC address.
>
> Now we have two ways to solve this problem.
> 1. The vhost learns MAC address from packet like as my first patch.
I do agree with Aaron this is not the right way.
> 2. The virtio notifies MAC address actively to vhost user .
Unfortunately, AFAIK, there is no way to achieve that so far. we could
either let virtio/QEMU to expose the CQ to vhost or add a new VHOST_USER
message to carry the mac address. While vhost-user is a generic interface
adding a virtio-net specific message also doesn't seem quite right.
Exposing CQ is probably the best we can do.
Anyway, both need spec change.
--yliu
>
> In my opinions, if we treat it as a device, we should allocate
> MAC address for the device when the VM started.
>
> Which one do you think better?
>
>
>
> Best Regards,
> Chen Hailin
> chenhl@arraynetworks.com.cn
>
> From: Aaron Conole
> Date: 2017-11-18 10:00
> To: Hailin Chen
> CC: ovs-dev@openvswitch.org; Maxime Coquelin; cloud@arraynetworks.com.cn
> Subject: Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
> Hi Hailin,
>
> Hailin Chen <chenhl@arraynetworks.com.cn> writes:
>
> > The stp could not work on netdev-dpdk if network is loop.
> > Because the stp protocol negotiates designate port by sending
> > BPDU packets which contains MAC address.
> > However the device doesn't have MAC address in vhostuser type.
> > Thus, function send_bpdu_cb would not send BPDU packets.
> >
> > This patch will set the MAC for device when received first packet.
> >
> > Signed-off-by: Hailin Chen <chenhl@arraynetworks.com.cn>
> > ---
>
> Thanks for the patch.
>
> In general, I don't think this is the right approach to deal with this
> type of issue. I believe the problem statement is that OvS bridge is
> unaware of the guest MAC address - did I get it right? In that case, I
> would think that a better way to solve this would be to have virtio tell
> the mac address of the guest. I don't recall right now if that's
> allowed in the virtio spec, but I do remember some kind of negotiation
> features.
>
> I've CC'd Maxime, who is one of the maintainers of the virtio code from
> DPDK side. Perhaps there is an alternate way to solve this.
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
2017-11-27 14:27 ` [Qemu-devel] [dpdk-dev] " Yuanhan Liu
@ 2017-11-27 15:34 ` Tan, Jianfeng
-1 siblings, 0 replies; 14+ messages in thread
From: Tan, Jianfeng @ 2017-11-27 15:34 UTC (permalink / raw)
To: Yuanhan Liu, Chen Hailin
Cc: Aaron Conole, ovs-dev@openvswitch.org, Maxime Coquelin, cloud,
qemu-devel, dev
On 11/27/2017 10:27 PM, Yuanhan Liu wrote:
> On Fri, Nov 24, 2017 at 05:59:09PM +0800, Chen Hailin wrote:
>> Hi Aaron Conole && Jianfeng,
>>
>> The stp could not work in ovs-dpdk vhostuser.
>> Because the attached vhost device doesn't have MAC address.
>>
>> Now we have two ways to solve this problem.
>> 1. The vhost learns MAC address from packet like as my first patch.
> I do agree with Aaron this is not the right way.
I do think it should be the vswitch's responsibility to learn mac of
vhost port.
Except that it's the only feasible way without modifying the spec
(yuanhan already makes it very clear below), we can treat the vswitch as
a phsical switch, VM as a physical server, virtio/vhost port as a
back-to-back connected NICs, the only way of the physical switch to know
the mac of the NIC on the other side is ARP learning.
Might I ask why you don't think it's a right way?
Thanks,
Jianfeng
>
>> 2. The virtio notifies MAC address actively to vhost user .
> Unfortunately, AFAIK, there is no way to achieve that so far. we could
> either let virtio/QEMU to expose the CQ to vhost or add a new VHOST_USER
> message to carry the mac address. While vhost-user is a generic interface
> adding a virtio-net specific message also doesn't seem quite right.
> Exposing CQ is probably the best we can do.
>
> Anyway, both need spec change.
>
> --yliu
>> In my opinions, if we treat it as a device, we should allocate
>> MAC address for the device when the VM started.
>>
>> Which one do you think better?
>>
>>
>>
>> Best Regards,
>> Chen Hailin
>> chenhl@arraynetworks.com.cn
>>
>> From: Aaron Conole
>> Date: 2017-11-18 10:00
>> To: Hailin Chen
>> CC: ovs-dev@openvswitch.org; Maxime Coquelin; cloud@arraynetworks.com.cn
>> Subject: Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
>> Hi Hailin,
>>
>> Hailin Chen <chenhl@arraynetworks.com.cn> writes:
>>
>>> The stp could not work on netdev-dpdk if network is loop.
>>> Because the stp protocol negotiates designate port by sending
>>> BPDU packets which contains MAC address.
>>> However the device doesn't have MAC address in vhostuser type.
>>> Thus, function send_bpdu_cb would not send BPDU packets.
>>>
>>> This patch will set the MAC for device when received first packet.
>>>
>>> Signed-off-by: Hailin Chen <chenhl@arraynetworks.com.cn>
>>> ---
>>
>> Thanks for the patch.
>>
>> In general, I don't think this is the right approach to deal with this
>> type of issue. I believe the problem statement is that OvS bridge is
>> unaware of the guest MAC address - did I get it right? In that case, I
>> would think that a better way to solve this would be to have virtio tell
>> the mac address of the guest. I don't recall right now if that's
>> allowed in the virtio spec, but I do remember some kind of negotiation
>> features.
>>
>> I've CC'd Maxime, who is one of the maintainers of the virtio code from
>> DPDK side. Perhaps there is an alternate way to solve this.
>> _______________________________________________
>> dev mailing list
>> dev@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [dpdk-dev] [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
@ 2017-11-27 15:34 ` Tan, Jianfeng
0 siblings, 0 replies; 14+ messages in thread
From: Tan, Jianfeng @ 2017-11-27 15:34 UTC (permalink / raw)
To: Yuanhan Liu, Chen Hailin
Cc: Aaron Conole, ovs-dev@openvswitch.org, Maxime Coquelin, cloud,
qemu-devel, dev
On 11/27/2017 10:27 PM, Yuanhan Liu wrote:
> On Fri, Nov 24, 2017 at 05:59:09PM +0800, Chen Hailin wrote:
>> Hi Aaron Conole && Jianfeng,
>>
>> The stp could not work in ovs-dpdk vhostuser.
>> Because the attached vhost device doesn't have MAC address.
>>
>> Now we have two ways to solve this problem.
>> 1. The vhost learns MAC address from packet like as my first patch.
> I do agree with Aaron this is not the right way.
I do think it should be the vswitch's responsibility to learn mac of
vhost port.
Except that it's the only feasible way without modifying the spec
(yuanhan already makes it very clear below), we can treat the vswitch as
a phsical switch, VM as a physical server, virtio/vhost port as a
back-to-back connected NICs, the only way of the physical switch to know
the mac of the NIC on the other side is ARP learning.
Might I ask why you don't think it's a right way?
Thanks,
Jianfeng
>
>> 2. The virtio notifies MAC address actively to vhost user .
> Unfortunately, AFAIK, there is no way to achieve that so far. we could
> either let virtio/QEMU to expose the CQ to vhost or add a new VHOST_USER
> message to carry the mac address. While vhost-user is a generic interface
> adding a virtio-net specific message also doesn't seem quite right.
> Exposing CQ is probably the best we can do.
>
> Anyway, both need spec change.
>
> --yliu
>> In my opinions, if we treat it as a device, we should allocate
>> MAC address for the device when the VM started.
>>
>> Which one do you think better?
>>
>>
>>
>> Best Regards,
>> Chen Hailin
>> chenhl@arraynetworks.com.cn
>>
>> From: Aaron Conole
>> Date: 2017-11-18 10:00
>> To: Hailin Chen
>> CC: ovs-dev@openvswitch.org; Maxime Coquelin; cloud@arraynetworks.com.cn
>> Subject: Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
>> Hi Hailin,
>>
>> Hailin Chen <chenhl@arraynetworks.com.cn> writes:
>>
>>> The stp could not work on netdev-dpdk if network is loop.
>>> Because the stp protocol negotiates designate port by sending
>>> BPDU packets which contains MAC address.
>>> However the device doesn't have MAC address in vhostuser type.
>>> Thus, function send_bpdu_cb would not send BPDU packets.
>>>
>>> This patch will set the MAC for device when received first packet.
>>>
>>> Signed-off-by: Hailin Chen <chenhl@arraynetworks.com.cn>
>>> ---
>>
>> Thanks for the patch.
>>
>> In general, I don't think this is the right approach to deal with this
>> type of issue. I believe the problem statement is that OvS bridge is
>> unaware of the guest MAC address - did I get it right? In that case, I
>> would think that a better way to solve this would be to have virtio tell
>> the mac address of the guest. I don't recall right now if that's
>> allowed in the virtio spec, but I do remember some kind of negotiation
>> features.
>>
>> I've CC'd Maxime, who is one of the maintainers of the virtio code from
>> DPDK side. Perhaps there is an alternate way to solve this.
>> _______________________________________________
>> dev mailing list
>> dev@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
2017-11-27 15:34 ` [Qemu-devel] [dpdk-dev] " Tan, Jianfeng
@ 2017-11-27 17:01 ` Aaron Conole
-1 siblings, 0 replies; 14+ messages in thread
From: Aaron Conole @ 2017-11-27 17:01 UTC (permalink / raw)
To: Tan, Jianfeng
Cc: Yuanhan Liu, Chen Hailin, ovs-dev@openvswitch.org,
Maxime Coquelin, cloud, qemu-devel, dev
"Tan, Jianfeng" <jianfeng.tan@intel.com> writes:
> On 11/27/2017 10:27 PM, Yuanhan Liu wrote:
>> On Fri, Nov 24, 2017 at 05:59:09PM +0800, Chen Hailin wrote:
>>> Hi Aaron Conole && Jianfeng,
>>>
>>> The stp could not work in ovs-dpdk vhostuser.
>>> Because the attached vhost device doesn't have MAC address.
>>>
>>> Now we have two ways to solve this problem.
>>> 1. The vhost learns MAC address from packet like as my first patch.
>> I do agree with Aaron this is not the right way.
>
> I do think it should be the vswitch's responsibility to learn mac of
> vhost port.
>
> Except that it's the only feasible way without modifying the spec
> (yuanhan already makes it very clear below), we can treat the vswitch
> as a phsical switch, VM as a physical server, virtio/vhost port as a
> back-to-back connected NICs, the only way of the physical switch to
> know the mac of the NIC on the other side is ARP learning.
>
> Might I ask why you don't think it's a right way?
As a quick example, I think a malicious guest in a multi-tenant
environment could send traffic out to manipulate this feature into
learning an incorrect mac address.
To get this right requires doing deep packet inspection, and making sure
to only learn based on certain l2 traffic.
> Thanks,
> Jianfeng
>
>>
>>> 2. The virtio notifies MAC address actively to vhost user .
>> Unfortunately, AFAIK, there is no way to achieve that so far. we could
>> either let virtio/QEMU to expose the CQ to vhost or add a new VHOST_USER
>> message to carry the mac address. While vhost-user is a generic interface
>> adding a virtio-net specific message also doesn't seem quite right.
>> Exposing CQ is probably the best we can do.
>>
>> Anyway, both need spec change.
>>
>> --yliu
>>> In my opinions, if we treat it as a device, we should allocate
>>> MAC address for the device when the VM started.
>>>
>>> Which one do you think better?
>>>
>>>
>>>
>>> Best Regards,
>>> Chen Hailin
>>> chenhl@arraynetworks.com.cn
>>> From: Aaron Conole
>>> Date: 2017-11-18 10:00
>>> To: Hailin Chen
>>> CC: ovs-dev@openvswitch.org; Maxime Coquelin; cloud@arraynetworks.com.cn
>>> Subject: Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain
>>> mac address when received first packet in vhost type
>>> Hi Hailin,
>>> Hailin Chen <chenhl@arraynetworks.com.cn> writes:
>>>
>>>> The stp could not work on netdev-dpdk if network is loop.
>>>> Because the stp protocol negotiates designate port by sending
>>>> BPDU packets which contains MAC address.
>>>> However the device doesn't have MAC address in vhostuser type.
>>>> Thus, function send_bpdu_cb would not send BPDU packets.
>>>>
>>>> This patch will set the MAC for device when received first packet.
>>>>
>>>> Signed-off-by: Hailin Chen <chenhl@arraynetworks.com.cn>
>>>> ---
>>> Thanks for the patch.
>>> In general, I don't think this is the right approach to deal with
>>> this
>>> type of issue. I believe the problem statement is that OvS bridge is
>>> unaware of the guest MAC address - did I get it right? In that case, I
>>> would think that a better way to solve this would be to have virtio tell
>>> the mac address of the guest. I don't recall right now if that's
>>> allowed in the virtio spec, but I do remember some kind of negotiation
>>> features.
>>> I've CC'd Maxime, who is one of the maintainers of the virtio
>>> code from
>>> DPDK side. Perhaps there is an alternate way to solve this.
>>> _______________________________________________
>>> dev mailing list
>>> dev@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [dpdk-dev] [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
@ 2017-11-27 17:01 ` Aaron Conole
0 siblings, 0 replies; 14+ messages in thread
From: Aaron Conole @ 2017-11-27 17:01 UTC (permalink / raw)
To: Tan, Jianfeng
Cc: Yuanhan Liu, Chen Hailin, ovs-dev@openvswitch.org,
Maxime Coquelin, cloud, qemu-devel, dev
"Tan, Jianfeng" <jianfeng.tan@intel.com> writes:
> On 11/27/2017 10:27 PM, Yuanhan Liu wrote:
>> On Fri, Nov 24, 2017 at 05:59:09PM +0800, Chen Hailin wrote:
>>> Hi Aaron Conole && Jianfeng,
>>>
>>> The stp could not work in ovs-dpdk vhostuser.
>>> Because the attached vhost device doesn't have MAC address.
>>>
>>> Now we have two ways to solve this problem.
>>> 1. The vhost learns MAC address from packet like as my first patch.
>> I do agree with Aaron this is not the right way.
>
> I do think it should be the vswitch's responsibility to learn mac of
> vhost port.
>
> Except that it's the only feasible way without modifying the spec
> (yuanhan already makes it very clear below), we can treat the vswitch
> as a phsical switch, VM as a physical server, virtio/vhost port as a
> back-to-back connected NICs, the only way of the physical switch to
> know the mac of the NIC on the other side is ARP learning.
>
> Might I ask why you don't think it's a right way?
As a quick example, I think a malicious guest in a multi-tenant
environment could send traffic out to manipulate this feature into
learning an incorrect mac address.
To get this right requires doing deep packet inspection, and making sure
to only learn based on certain l2 traffic.
> Thanks,
> Jianfeng
>
>>
>>> 2. The virtio notifies MAC address actively to vhost user .
>> Unfortunately, AFAIK, there is no way to achieve that so far. we could
>> either let virtio/QEMU to expose the CQ to vhost or add a new VHOST_USER
>> message to carry the mac address. While vhost-user is a generic interface
>> adding a virtio-net specific message also doesn't seem quite right.
>> Exposing CQ is probably the best we can do.
>>
>> Anyway, both need spec change.
>>
>> --yliu
>>> In my opinions, if we treat it as a device, we should allocate
>>> MAC address for the device when the VM started.
>>>
>>> Which one do you think better?
>>>
>>>
>>>
>>> Best Regards,
>>> Chen Hailin
>>> chenhl@arraynetworks.com.cn
>>> From: Aaron Conole
>>> Date: 2017-11-18 10:00
>>> To: Hailin Chen
>>> CC: ovs-dev@openvswitch.org; Maxime Coquelin; cloud@arraynetworks.com.cn
>>> Subject: Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain
>>> mac address when received first packet in vhost type
>>> Hi Hailin,
>>> Hailin Chen <chenhl@arraynetworks.com.cn> writes:
>>>
>>>> The stp could not work on netdev-dpdk if network is loop.
>>>> Because the stp protocol negotiates designate port by sending
>>>> BPDU packets which contains MAC address.
>>>> However the device doesn't have MAC address in vhostuser type.
>>>> Thus, function send_bpdu_cb would not send BPDU packets.
>>>>
>>>> This patch will set the MAC for device when received first packet.
>>>>
>>>> Signed-off-by: Hailin Chen <chenhl@arraynetworks.com.cn>
>>>> ---
>>> Thanks for the patch.
>>> In general, I don't think this is the right approach to deal with
>>> this
>>> type of issue. I believe the problem statement is that OvS bridge is
>>> unaware of the guest MAC address - did I get it right? In that case, I
>>> would think that a better way to solve this would be to have virtio tell
>>> the mac address of the guest. I don't recall right now if that's
>>> allowed in the virtio spec, but I do remember some kind of negotiation
>>> features.
>>> I've CC'd Maxime, who is one of the maintainers of the virtio
>>> code from
>>> DPDK side. Perhaps there is an alternate way to solve this.
>>> _______________________________________________
>>> dev mailing list
>>> dev@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <f7tfu8zodu2.fsf-uA3yvN0JDQ2XctSiLedv3RcY2uh10dtjAL8bYrjMMd8@public.gmane.org>]
* Re: [dpdk-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
2017-11-27 17:01 ` [Qemu-devel] [dpdk-dev] " Aaron Conole
@ 2017-11-28 16:06 ` Tan, Jianfeng
-1 siblings, 0 replies; 14+ messages in thread
From: Tan, Jianfeng @ 2017-11-28 16:06 UTC (permalink / raw)
To: Aaron Conole
Cc: ovs-dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, cloud,
qemu-devel, dev, Maxime Coquelin, Chen Hailin
On 11/28/2017 1:01 AM, Aaron Conole wrote:
> "Tan, Jianfeng" <jianfeng.tan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> writes:
>
>> On 11/27/2017 10:27 PM, Yuanhan Liu wrote:
>>> On Fri, Nov 24, 2017 at 05:59:09PM +0800, Chen Hailin wrote:
>>>> Hi Aaron Conole && Jianfeng,
>>>>
>>>> The stp could not work in ovs-dpdk vhostuser.
>>>> Because the attached vhost device doesn't have MAC address.
>>>>
>>>> Now we have two ways to solve this problem.
>>>> 1. The vhost learns MAC address from packet like as my first patch.
>>> I do agree with Aaron this is not the right way.
>> I do think it should be the vswitch's responsibility to learn mac of
>> vhost port.
>>
>> Except that it's the only feasible way without modifying the spec
>> (yuanhan already makes it very clear below), we can treat the vswitch
>> as a phsical switch, VM as a physical server, virtio/vhost port as a
>> back-to-back connected NICs, the only way of the physical switch to
>> know the mac of the NIC on the other side is ARP learning.
>>
>> Might I ask why you don't think it's a right way?
> As a quick example, I think a malicious guest in a multi-tenant
> environment could send traffic out to manipulate this feature into
> learning an incorrect mac address.
Instead, I think it's not right to stop such mac spoofing behavior
(suppose someone wants to have such an experiment in an overlay
networking). And it actually only affects one “LAN", instead of all "LANs".
And it's usually not the switch's responsibility to detect mac spoofing
behavior IMHO.
> To get this right requires doing deep packet inspection, and making sure
> to only learn based on certain l2 traffic.
>
Yes, should learn based on ARP packets. Your concern is the performance?
I suppose there is not to many such packets.
Thanks,
Jianfeng
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [dpdk-dev] [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
@ 2017-11-28 16:06 ` Tan, Jianfeng
0 siblings, 0 replies; 14+ messages in thread
From: Tan, Jianfeng @ 2017-11-28 16:06 UTC (permalink / raw)
To: Aaron Conole
Cc: Yuanhan Liu, Chen Hailin, ovs-dev@openvswitch.org,
Maxime Coquelin, cloud, qemu-devel, dev
On 11/28/2017 1:01 AM, Aaron Conole wrote:
> "Tan, Jianfeng" <jianfeng.tan@intel.com> writes:
>
>> On 11/27/2017 10:27 PM, Yuanhan Liu wrote:
>>> On Fri, Nov 24, 2017 at 05:59:09PM +0800, Chen Hailin wrote:
>>>> Hi Aaron Conole && Jianfeng,
>>>>
>>>> The stp could not work in ovs-dpdk vhostuser.
>>>> Because the attached vhost device doesn't have MAC address.
>>>>
>>>> Now we have two ways to solve this problem.
>>>> 1. The vhost learns MAC address from packet like as my first patch.
>>> I do agree with Aaron this is not the right way.
>> I do think it should be the vswitch's responsibility to learn mac of
>> vhost port.
>>
>> Except that it's the only feasible way without modifying the spec
>> (yuanhan already makes it very clear below), we can treat the vswitch
>> as a phsical switch, VM as a physical server, virtio/vhost port as a
>> back-to-back connected NICs, the only way of the physical switch to
>> know the mac of the NIC on the other side is ARP learning.
>>
>> Might I ask why you don't think it's a right way?
> As a quick example, I think a malicious guest in a multi-tenant
> environment could send traffic out to manipulate this feature into
> learning an incorrect mac address.
Instead, I think it's not right to stop such mac spoofing behavior
(suppose someone wants to have such an experiment in an overlay
networking). And it actually only affects one “LAN", instead of all "LANs".
And it's usually not the switch's responsibility to detect mac spoofing
behavior IMHO.
> To get this right requires doing deep packet inspection, and making sure
> to only learn based on certain l2 traffic.
>
Yes, should learn based on ARP packets. Your concern is the performance?
I suppose there is not to many such packets.
Thanks,
Jianfeng
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
2017-11-27 14:27 ` [Qemu-devel] [dpdk-dev] " Yuanhan Liu
@ 2017-11-27 16:14 ` Aaron Conole
-1 siblings, 0 replies; 14+ messages in thread
From: Aaron Conole @ 2017-11-27 16:14 UTC (permalink / raw)
To: Yuanhan Liu
Cc: Chen Hailin, jianfeng.tan, ovs-dev@openvswitch.org,
Maxime Coquelin, qemu-devel, dev
Yuanhan Liu <yliu@fridaylinux.org> writes:
> On Fri, Nov 24, 2017 at 05:59:09PM +0800, Chen Hailin wrote:
>> Hi Aaron Conole && Jianfeng,
>>
>> The stp could not work in ovs-dpdk vhostuser.
>> Because the attached vhost device doesn't have MAC address.
>>
>> Now we have two ways to solve this problem.
>> 1. The vhost learns MAC address from packet like as my first patch.
>
> I do agree with Aaron this is not the right way.
>
>> 2. The virtio notifies MAC address actively to vhost user .
>
> Unfortunately, AFAIK, there is no way to achieve that so far. we could
> either let virtio/QEMU to expose the CQ to vhost or add a new VHOST_USER
> message to carry the mac address. While vhost-user is a generic interface
> adding a virtio-net specific message also doesn't seem quite right.
> Exposing CQ is probably the best we can do.
>
> Anyway, both need spec change.
There are other possible ways. libvirt knows about the mac address from
the domain xml file. Perhaps it's possible to set the mac column in the
database to the correct value when the port is being created in ovs?
This would be an action taken by the orchestration tool.
Additionally, there's a mechanism in virtio-net to set the mac address
from the host to the guest. Is it possible to expose that functionality
through vhost-user?
Then when the orchestration tool sets the mac, it can be propagated, and
mac_in_use can reflect the appropriate value. I think that's a workable
solution, but I might have missed something.
> --yliu
>>
>> In my opinions, if we treat it as a device, we should allocate
>> MAC address for the device when the VM started.
>>
>> Which one do you think better?
>>
>>
>>
>> Best Regards,
>> Chen Hailin
>> chenhl@arraynetworks.com.cn
>>
>> From: Aaron Conole
>> Date: 2017-11-18 10:00
>> To: Hailin Chen
>> CC: ovs-dev@openvswitch.org; Maxime Coquelin; cloud@arraynetworks.com.cn
>> Subject: Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain
>> mac address when received first packet in vhost type
>> Hi Hailin,
>>
>> Hailin Chen <chenhl@arraynetworks.com.cn> writes:
>>
>> > The stp could not work on netdev-dpdk if network is loop.
>> > Because the stp protocol negotiates designate port by sending
>> > BPDU packets which contains MAC address.
>> > However the device doesn't have MAC address in vhostuser type.
>> > Thus, function send_bpdu_cb would not send BPDU packets.
>> >
>> > This patch will set the MAC for device when received first packet.
>> >
>> > Signed-off-by: Hailin Chen <chenhl@arraynetworks.com.cn>
>> > ---
>>
>> Thanks for the patch.
>>
>> In general, I don't think this is the right approach to deal with this
>> type of issue. I believe the problem statement is that OvS bridge is
>> unaware of the guest MAC address - did I get it right? In that case, I
>> would think that a better way to solve this would be to have virtio tell
>> the mac address of the guest. I don't recall right now if that's
>> allowed in the virtio spec, but I do remember some kind of negotiation
>> features.
>>
>> I've CC'd Maxime, who is one of the maintainers of the virtio code from
>> DPDK side. Perhaps there is an alternate way to solve this.
>> _______________________________________________
>> dev mailing list
>> dev@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [dpdk-dev] [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
@ 2017-11-27 16:14 ` Aaron Conole
0 siblings, 0 replies; 14+ messages in thread
From: Aaron Conole @ 2017-11-27 16:14 UTC (permalink / raw)
To: Yuanhan Liu
Cc: Chen Hailin, jianfeng.tan, ovs-dev@openvswitch.org,
Maxime Coquelin, qemu-devel, dev
Yuanhan Liu <yliu@fridaylinux.org> writes:
> On Fri, Nov 24, 2017 at 05:59:09PM +0800, Chen Hailin wrote:
>> Hi Aaron Conole && Jianfeng,
>>
>> The stp could not work in ovs-dpdk vhostuser.
>> Because the attached vhost device doesn't have MAC address.
>>
>> Now we have two ways to solve this problem.
>> 1. The vhost learns MAC address from packet like as my first patch.
>
> I do agree with Aaron this is not the right way.
>
>> 2. The virtio notifies MAC address actively to vhost user .
>
> Unfortunately, AFAIK, there is no way to achieve that so far. we could
> either let virtio/QEMU to expose the CQ to vhost or add a new VHOST_USER
> message to carry the mac address. While vhost-user is a generic interface
> adding a virtio-net specific message also doesn't seem quite right.
> Exposing CQ is probably the best we can do.
>
> Anyway, both need spec change.
There are other possible ways. libvirt knows about the mac address from
the domain xml file. Perhaps it's possible to set the mac column in the
database to the correct value when the port is being created in ovs?
This would be an action taken by the orchestration tool.
Additionally, there's a mechanism in virtio-net to set the mac address
from the host to the guest. Is it possible to expose that functionality
through vhost-user?
Then when the orchestration tool sets the mac, it can be propagated, and
mac_in_use can reflect the appropriate value. I think that's a workable
solution, but I might have missed something.
> --yliu
>>
>> In my opinions, if we treat it as a device, we should allocate
>> MAC address for the device when the VM started.
>>
>> Which one do you think better?
>>
>>
>>
>> Best Regards,
>> Chen Hailin
>> chenhl@arraynetworks.com.cn
>>
>> From: Aaron Conole
>> Date: 2017-11-18 10:00
>> To: Hailin Chen
>> CC: ovs-dev@openvswitch.org; Maxime Coquelin; cloud@arraynetworks.com.cn
>> Subject: Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain
>> mac address when received first packet in vhost type
>> Hi Hailin,
>>
>> Hailin Chen <chenhl@arraynetworks.com.cn> writes:
>>
>> > The stp could not work on netdev-dpdk if network is loop.
>> > Because the stp protocol negotiates designate port by sending
>> > BPDU packets which contains MAC address.
>> > However the device doesn't have MAC address in vhostuser type.
>> > Thus, function send_bpdu_cb would not send BPDU packets.
>> >
>> > This patch will set the MAC for device when received first packet.
>> >
>> > Signed-off-by: Hailin Chen <chenhl@arraynetworks.com.cn>
>> > ---
>>
>> Thanks for the patch.
>>
>> In general, I don't think this is the right approach to deal with this
>> type of issue. I believe the problem statement is that OvS bridge is
>> unaware of the guest MAC address - did I get it right? In that case, I
>> would think that a better way to solve this would be to have virtio tell
>> the mac address of the guest. I don't recall right now if that's
>> allowed in the virtio spec, but I do remember some kind of negotiation
>> features.
>>
>> I've CC'd Maxime, who is one of the maintainers of the virtio code from
>> DPDK side. Perhaps there is an alternate way to solve this.
>> _______________________________________________
>> dev mailing list
>> dev@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
2017-11-27 16:14 ` [Qemu-devel] [dpdk-dev] " Aaron Conole
@ 2017-11-27 16:35 ` Tan, Jianfeng
-1 siblings, 0 replies; 14+ messages in thread
From: Tan, Jianfeng @ 2017-11-27 16:35 UTC (permalink / raw)
To: Aaron Conole, Yuanhan Liu
Cc: Chen Hailin, ovs-dev@openvswitch.org, Maxime Coquelin, qemu-devel,
dev
On 11/28/2017 12:14 AM, Aaron Conole wrote:
> Yuanhan Liu <yliu@fridaylinux.org> writes:
>
>> On Fri, Nov 24, 2017 at 05:59:09PM +0800, Chen Hailin wrote:
>>> Hi Aaron Conole && Jianfeng,
>>>
>>> The stp could not work in ovs-dpdk vhostuser.
>>> Because the attached vhost device doesn't have MAC address.
>>>
>>> Now we have two ways to solve this problem.
>>> 1. The vhost learns MAC address from packet like as my first patch.
>> I do agree with Aaron this is not the right way.
>>
>>> 2. The virtio notifies MAC address actively to vhost user .
>> Unfortunately, AFAIK, there is no way to achieve that so far. we could
>> either let virtio/QEMU to expose the CQ to vhost or add a new VHOST_USER
>> message to carry the mac address. While vhost-user is a generic interface
>> adding a virtio-net specific message also doesn't seem quite right.
>> Exposing CQ is probably the best we can do.
>>
>> Anyway, both need spec change.
> There are other possible ways. libvirt knows about the mac address from
> the domain xml file. Perhaps it's possible to set the mac column in the
> database to the correct value when the port is being created in ovs?
> This would be an action taken by the orchestration tool.
In OVS db, we can only see vhost port, but not virtio port. That is to
say, we could use different mac for vhost port from virtio port,
especially when it works as a vrouter instead of vswitch.
>
> Additionally, there's a mechanism in virtio-net to set the mac address
> from the host to the guest. Is it possible to expose that functionality
> through vhost-user?
We can assign mac addr when starting QEMU. After that, I suppose we
cannot set mac addr any more, let alone setting it from vhost-user side
(vhost-user protocol does not support it yet).
Thanks,
Jianfeng
>
> Then when the orchestration tool sets the mac, it can be propagated, and
> mac_in_use can reflect the appropriate value. I think that's a workable
> solution, but I might have missed something.
>
>> --yliu
>>> In my opinions, if we treat it as a device, we should allocate
>>> MAC address for the device when the VM started.
>>>
>>> Which one do you think better?
>>>
>>>
>>>
>>> Best Regards,
>>> Chen Hailin
>>> chenhl@arraynetworks.com.cn
>>>
>>> From: Aaron Conole
>>> Date: 2017-11-18 10:00
>>> To: Hailin Chen
>>> CC: ovs-dev@openvswitch.org; Maxime Coquelin; cloud@arraynetworks.com.cn
>>> Subject: Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain
>>> mac address when received first packet in vhost type
>>> Hi Hailin,
>>>
>>> Hailin Chen <chenhl@arraynetworks.com.cn> writes:
>>>
>>>> The stp could not work on netdev-dpdk if network is loop.
>>>> Because the stp protocol negotiates designate port by sending
>>>> BPDU packets which contains MAC address.
>>>> However the device doesn't have MAC address in vhostuser type.
>>>> Thus, function send_bpdu_cb would not send BPDU packets.
>>>>
>>>> This patch will set the MAC for device when received first packet.
>>>>
>>>> Signed-off-by: Hailin Chen <chenhl@arraynetworks.com.cn>
>>>> ---
>>>
>>> Thanks for the patch.
>>>
>>> In general, I don't think this is the right approach to deal with this
>>> type of issue. I believe the problem statement is that OvS bridge is
>>> unaware of the guest MAC address - did I get it right? In that case, I
>>> would think that a better way to solve this would be to have virtio tell
>>> the mac address of the guest. I don't recall right now if that's
>>> allowed in the virtio spec, but I do remember some kind of negotiation
>>> features.
>>>
>>> I've CC'd Maxime, who is one of the maintainers of the virtio code from
>>> DPDK side. Perhaps there is an alternate way to solve this.
>>> _______________________________________________
>>> dev mailing list
>>> dev@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [dpdk-dev] [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
@ 2017-11-27 16:35 ` Tan, Jianfeng
0 siblings, 0 replies; 14+ messages in thread
From: Tan, Jianfeng @ 2017-11-27 16:35 UTC (permalink / raw)
To: Aaron Conole, Yuanhan Liu
Cc: Chen Hailin, ovs-dev@openvswitch.org, Maxime Coquelin, qemu-devel,
dev
On 11/28/2017 12:14 AM, Aaron Conole wrote:
> Yuanhan Liu <yliu@fridaylinux.org> writes:
>
>> On Fri, Nov 24, 2017 at 05:59:09PM +0800, Chen Hailin wrote:
>>> Hi Aaron Conole && Jianfeng,
>>>
>>> The stp could not work in ovs-dpdk vhostuser.
>>> Because the attached vhost device doesn't have MAC address.
>>>
>>> Now we have two ways to solve this problem.
>>> 1. The vhost learns MAC address from packet like as my first patch.
>> I do agree with Aaron this is not the right way.
>>
>>> 2. The virtio notifies MAC address actively to vhost user .
>> Unfortunately, AFAIK, there is no way to achieve that so far. we could
>> either let virtio/QEMU to expose the CQ to vhost or add a new VHOST_USER
>> message to carry the mac address. While vhost-user is a generic interface
>> adding a virtio-net specific message also doesn't seem quite right.
>> Exposing CQ is probably the best we can do.
>>
>> Anyway, both need spec change.
> There are other possible ways. libvirt knows about the mac address from
> the domain xml file. Perhaps it's possible to set the mac column in the
> database to the correct value when the port is being created in ovs?
> This would be an action taken by the orchestration tool.
In OVS db, we can only see vhost port, but not virtio port. That is to
say, we could use different mac for vhost port from virtio port,
especially when it works as a vrouter instead of vswitch.
>
> Additionally, there's a mechanism in virtio-net to set the mac address
> from the host to the guest. Is it possible to expose that functionality
> through vhost-user?
We can assign mac addr when starting QEMU. After that, I suppose we
cannot set mac addr any more, let alone setting it from vhost-user side
(vhost-user protocol does not support it yet).
Thanks,
Jianfeng
>
> Then when the orchestration tool sets the mac, it can be propagated, and
> mac_in_use can reflect the appropriate value. I think that's a workable
> solution, but I might have missed something.
>
>> --yliu
>>> In my opinions, if we treat it as a device, we should allocate
>>> MAC address for the device when the VM started.
>>>
>>> Which one do you think better?
>>>
>>>
>>>
>>> Best Regards,
>>> Chen Hailin
>>> chenhl@arraynetworks.com.cn
>>>
>>> From: Aaron Conole
>>> Date: 2017-11-18 10:00
>>> To: Hailin Chen
>>> CC: ovs-dev@openvswitch.org; Maxime Coquelin; cloud@arraynetworks.com.cn
>>> Subject: Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain
>>> mac address when received first packet in vhost type
>>> Hi Hailin,
>>>
>>> Hailin Chen <chenhl@arraynetworks.com.cn> writes:
>>>
>>>> The stp could not work on netdev-dpdk if network is loop.
>>>> Because the stp protocol negotiates designate port by sending
>>>> BPDU packets which contains MAC address.
>>>> However the device doesn't have MAC address in vhostuser type.
>>>> Thus, function send_bpdu_cb would not send BPDU packets.
>>>>
>>>> This patch will set the MAC for device when received first packet.
>>>>
>>>> Signed-off-by: Hailin Chen <chenhl@arraynetworks.com.cn>
>>>> ---
>>>
>>> Thanks for the patch.
>>>
>>> In general, I don't think this is the right approach to deal with this
>>> type of issue. I believe the problem statement is that OvS bridge is
>>> unaware of the guest MAC address - did I get it right? In that case, I
>>> would think that a better way to solve this would be to have virtio tell
>>> the mac address of the guest. I don't recall right now if that's
>>> allowed in the virtio spec, but I do remember some kind of negotiation
>>> features.
>>>
>>> I've CC'd Maxime, who is one of the maintainers of the virtio code from
>>> DPDK side. Perhaps there is an alternate way to solve this.
>>> _______________________________________________
>>> dev mailing list
>>> dev@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
^ permalink raw reply [flat|nested] 14+ messages in thread