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. 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
