On Thu, Feb 12, 2015 at 2:59 PM, David Evans <[email protected]> wrote: > Hi Pravin, > > While trying to figure this out - I'm looking at netdev-vport.c and > netdev-dpdk.c > I could conceivably integrate the vport's build/push/pop/get/set/config > for GRE into the DPDK netdev-dpdk.c. > > Then I would only need one bridge and would not require the linux > networking/routing. > The reason for using two bridge is that we want to share core with linux networking so that there is no need to rewrite those components and management utilities.
> Does that sound foolish or wise to you? > > Regards, > Dave. > > On 2/12/15, 3:38 PM, "Pravin Shelar" <[email protected]> wrote: > >>On Thu, Feb 12, 2015 at 9:29 AM, David Evans <[email protected]> >>wrote: >>> BTW- it works fine when b0 bridge type is NOT netdev and port is not >>> accessed via DPDK. >>> Something in the userspace data path may be broken? >>> >> >>Can you try same test with netdev datapath and userspace tunneling? >> >>> On 2/12/15, 9:16 AM, "David Evans" <[email protected]> wrote: >>> >>>>Hi Pravin, >>>> >>>>Thank you for helping out. >>>> >>>>As you saw below from ofproto/trace, the b0 bridge Datapath Actions says >>>>it sends out gre packets with a header src .102 dest .101 destination >>>>But the packet captured on the receiving host(C)ös ethernet port is as >>>>follows (GRE header in tact from 2F) but the outer MAC & IP are 00... >>>> >>>>00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 >>>>00 00 00 00 00 00 40 2F 46 9F C0 A8 38 66 C0 A8 >>>>38 65 00 00 65 58 00 00 04 04 12 34 00 00 04 56 >>>>78 90 08 00 45 00 01 EE 00 00 00 00 40 FF A6 B9 >>>>C0 A8 A8 05 C0 A8 A8 01 >>>> >>>>Trying to trace this through: >>>> >>>>1) How did the Datapath Actions on b0 work out the src ip? >>>> >>>> >>>>2) What is supposed to happen to the packet when it leaves the first >>>>bridge b0? >>>>How does it get to b1? I am guessing linux host routing? >>>> >>>>3) Could B1 be corrupting the header for some reason? >>>> >>>>4Š other possible factors ( netdev bridge? - DPDK ports? linux stack >>>>arp >>>>cache issue?) >>>> >>>>I can ping both directions between 102 & 101 across the wire. So that >>>>connection is good. >>>> >>>> >>>> >>>> >>>> >>>> >>>>default_hugepagesz=2M hugepagesz=2M hugepages=2048 >>>> >>>>On 2/11/15, 6:55 PM, "Pravin Shelar" <[email protected]> wrote: >>>> >>>>>On Tue, Feb 10, 2015 at 1:52 PM, David Evans >>>>><[email protected]> >>>>>wrote: >>>>>> Hi OVS, >>>>>> >>>>>> I have 3.18 kernel containing ip_gre & Ovs 2.3.90 & Dpdk 1.7.1 >>>>>> >>>>>Userspace tunneling does not need ip_gre module, tunneling is handled >>>>>in userspace. >>>>> >>>>>> I find that the outer ip & mac are not populated ??? The >>>>>>ofproto/trace >>>>>> output thinks that the gre output will have the right src/dest on the >>>>>>outer >>>>>> but then it(C)ös goneŠ >>>>>> >>>>>What do you mean by "its gone"? Can you post tcpdump for ping test? >>>>> >>>>> >>>>>> a bug? >>>>>> am I missing some setup? >>>>>> Wrong kernel ip_gre? >>>>>> >>>>>> Originating GRE: >>>>>> ovs-vsctl add-br b0 -- set bridge b0 datapath_type=netdev >>>>>> ovs-vsctl add-port b0 gre0 -- set Interface gre0 type=gre >>>>>> options:remote_ip=192.168.56.101 >>>>>> ovs-vsctl add-port b0 dpdk0 -- set Interface dpdk0 type=dpdk >>>>>> >>>>>> Output Bridge: >>>>>> ovs-vsctl add-br b1 -- set bridge b1 datapath_type=netdev >>>>>> ovs-vsctl add-port b1 dpdk1 -- set Interface dpdk1 type=dpdk >>>>>> ifconfig b1 192.168.56.102 netmask 255.255.255.0 >>>>>> >>>>>> Set up flows: >>>>>> ovs-ofctl del-flows b0 >>>>>> ovs-ofctl del-flows b1 >>>>>> -force traffic to gre from dpdk0 >>>>>> ovs-ofctl add-flow b0 in_port=2,action=output:1 >>>>>> ovs-ofctl add-flow b0 in_port=1,action=output:0 >>>>>> -force traffic from b1 to output >>>>>> ovs-ofctl add-flow b1 in_port=LOCAL,action=output:1 >>>>>> ovs-ofctl add-flow b1 in_port=1,action=output:LOCAL >>>>>> >>>>>> A ofproto/trace says >>>>>> >>>>>> ovs-appctl ofproto/trace b0 in_port=1,dl_dst=00:e0:ed:52:97:cd >>>>>> Bridge: b0 >>>>>> Flow: >>>>>> >>>>>>in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:e0:ed:52: >>>>>>97 >>>>>>: >>>>>>cd,dl_type=0x0000 >>>>>> >>>>>> Rule: table=0 cookie=0 in_port=1 >>>>>> OpenFlow actions=output:2 >>>>>> >>>>>> Final flow: >>>>>> >>>>>>in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:e0:ed:52: >>>>>>97 >>>>>>: >>>>>>cd,dl_type=0x0000 >>>>>> Megaflow: recirc_id=0,in_port=1,dl_type=0x0000 >>>>>> Datapath actions: >>>>>> >>>>>>tnl_push(tnl_port(5),header(size=38,type=3,eth(dst=00:00:04:04:12:34,s >>>>>>rc >>>>>>= >>>>>>00:e0:ed:52:97:cb,dl_type=0x0800),ipv4(src=192.168.56.102,dst=192.168. >>>>>>56 >>>>>>. >>>>>>101,proto=47,tos=0,ttl=64,frag=0x40),gre((flags=0x0,proto=0x6558))),ou >>>>>>t_ >>>>>>p >>>>>>ort(2)) >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Dave >>>>>> >>>>>> _______________________________________________ >>>>>> discuss mailing list >>>>>> [email protected] >>>>>> http://openvswitch.org/mailman/listinfo/discuss >>>>>> >>>> >>>> >>> >>> > > _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
