The topology diagram provided makes it clear that all the packet flow is internal to a single PF. Maybe check that the nic bridge is working as expected; you don’t need OVS running to verify that.
From: Advith Nagappa <[email protected]> Date: Saturday, April 1, 2017 at 11:18 PM To: Purnendu <[email protected]> Cc: Darrell Ball <[email protected]>, discuss <[email protected]> Subject: Re: [ovs-discuss] SR-IOV with Open vSwitch Hi Purnendu, Thank you for the response. I d like to apologize for the mistake that I made in the diagram. I mixed up the ip addresses in my init diagram. The configuration actually is: 10.0.0.1(SOURCE) ---- 10.0.0.3(OVS) ------- 10.0.0.2(SINK) @10.0.0.1<https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.0.1&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=TCOMlrhKLGP3O2h7ruzgIA6-5j5iuvyDEC0752E3Qyk&s=N5ubGAAnPxDmlL4E0r00s-bFdN1yzadL9FDlviOSWm0&e=> ip route 10.0.0.2 gw 10.0.0.3 @10.0.0.3<https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.0.3&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=TCOMlrhKLGP3O2h7ruzgIA6-5j5iuvyDEC0752E3Qyk&s=droEZDI_huugicsU3sLA4XsgNIUUyMPbdUGUTRJVWHA&e=> ip_forwarding=on ovs-ofctl add-flow br0 priority=1111,dl_type=0x0800,nw_proto=17,nw_src=10.0.0.1,nw_dst=10.0.0.2,actions= On Apr 1, 2017 23:05, "Purnendu" <[email protected]<mailto:[email protected]>> wrote: Hi Advith,Darrel, With SR-IOV configured the packet flow among the VMs would traverse through the PHY. I put a diagram. BR, Purnendu On Sat, Apr 1, 2017 at 1:38 PM, Advith Nagappa <[email protected]<mailto:[email protected]>> wrote: I have attached a sketch of the topology. I send 14 packets from Source(10.0.0.1), I receive 14 at Sink.(10.0.0.2) I also see 14 packets hitting the rule at OVS(drop rule at 10.0.0.3) cookie=0x0, duration=123.175s, table=0, n_packets=14, n_bytes=60, idle_age=2, priority=1111,udp,nw_src=10.0.0.1,nw_dst=10.0.0.2 actions=drop And I can say with confidence that there are no other UDP packets in the system. On Fri, Mar 31, 2017 at 10:45 PM, Darrell Ball <[email protected]<mailto:[email protected]>> wrote: From: Advith Nagappa <[email protected]<mailto:[email protected]>> Date: Friday, March 31, 2017 at 1:14 PM To: Darrell Ball <[email protected]<mailto:[email protected]>> Cc: discuss <[email protected]<mailto:[email protected]>> Subject: Re: [ovs-discuss] SR-IOV with Open vSwitch Darrell, Thank you for the resources and the response. I am not using a Linux bridge at host. Just SR-IOV to pass through the hypervisor. My guess here is that the although the three guests are assigned one virtual functions(VF) each, since all three VFs are sliced out of the same underlying Physical function (and this they are.), the rules at the OVS are somehow overridden. I don't know if this guess is anywhere close to being accurate.. The overriding hypothesis seems unlikely, at least by what I understand by the term. It would be helpful to have a diagram of packet sourcing and sinking; i.e. where are the packets sent from and where is the counting of the received ones - “but the packet is not dropped:” Also, are the “received packets” the UDP packets you are tracking or some other ones. On Mar 31, 2017 01:16, "Darrell Ball" <[email protected]<mailto:[email protected]>> wrote: From: <[email protected]<mailto:[email protected]>> on behalf of Advith Nagappa <[email protected]<mailto:[email protected]>> Date: Wednesday, March 29, 2017 at 9:39 PM To: discuss <[email protected]<mailto:[email protected]>> Subject: [ovs-discuss] SR-IOV with Open vSwitch Hello All, Has anyone used SR-IOV with Open vSwitch(in a guest)? My understanding is that SR-IOV is hypervisor(host) by/pass, Hence using OVS at that level would not make sense.. So I tried deploying OVS in an SR-IOV enabled guest, and here is what I observed.. I have one virtual function within my guest, called ens7. I have added that to by OVS-bridge.. d5f266fc-a6f1-448e-91c5-e6db8748f73f Bridge "br0" Port "ens7" Interface "ens7" Port "br0" Interface "br0" type: internal I also, added the following rule: ovs-ofctl add-flow br0 priority=1111,dl_type=0x0800,nw_proto=17,nw_src=10.0.0.1,nw_dst=10.0.0.2,actions= However every time I send a UDP datagram, I see that this rule is hit!, but the packet is not dropped: cookie=0x0, duration=123.175s, table=0, n_packets=14, n_bytes=60, idle_age=2, priority=1111,udp,nw_src=10.0.0.1,nw_dst=10.0.0.2 actions=drop The thing here is 10.0.0.1 and 10.0.0.2 share a physical function,.. and, despite the rule hit, the datagram is forwarded, I wonder what may be causing this? I am guessing some kind of L2 switching at the NIC level, which overrides OVS? Does anyone have an experience with this.. You are running OVS in the VM(s), not the host. I assume you are sending packets in one direction only and are constantly hitting an L2 broadcast case in the Linux bridge in the host (this is also an assumption, since you don’t delineate all your config. and topology). So, I guess one copy of the packet is bypassing OVS in the VM and another copy is sent to OVS in the VM to be dropped. Below link has more information and child links from there. https://github.com/intel/SDN-NFV-Hands-on-Samples/blob/master/SR-IOV_DPDK_Hands-on_Lab/docs/SR-IOV-HandsOn-IEEE.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_intel_SDN-2DNFV-2DHands-2Don-2DSamples_blob_master_SR-2DIOV-5FDPDK-5FHands-2Don-5FLab_docs_SR-2DIOV-2DHandsOn-2DIEEE.pdf&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=YxFaqFip6Yx8m_S1rRQJOt69mM8X50oOAA7F1TpEwNc&s=utBGEpRDhujM_F5GBaXHebC6S9K9UA0kf-o18GeeV8M&e=> Best Regards Advith Nagappa _______________________________________________ discuss mailing list [email protected]<mailto:[email protected]> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=TCOMlrhKLGP3O2h7ruzgIA6-5j5iuvyDEC0752E3Qyk&s=rX_CKKTP4q_zTl5MMTxYVX1IiJcSHfjM7OdTQyzRYuU&e=> -- with regards, Purnendu Ghosh
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
