On Wed, Jun 13, 2012 at 7:58 PM, Jesse Gross <je...@nicira.com> wrote: > On Thu, Jun 14, 2012 at 4:51 AM, ravi kerur <rke...@gmail.com> wrote: >> Ok got it. At least I am sensing that OVS will/should be optimized for >> both core and edge cases. I have taken care of comments from Pravin >> and I think we are waiting for Ben's input on ttl handling? > > It's not a question of optimization. If you implement something it > needs to be properly designed and work. The things you are > implementing have different use cases so you need to think both about > those and that fact that OVS/OpenFlow are designed to enable new uses. > You must come up with solutions that are flexible and extensible, not > just ones that address your current use case.
<rk> what are those new use cases? atleast I would like to understand that > >> There are additional things that needs to be addressed as well >> >> 1. offload code review, it's currently generic enough and getting near >> line rate performance numbers. > > You can't just take what is done for vlans and copy that. There is > far too much code that you're adding to OVS. Did you read what I > wrote earlier about where to start?: <rk> How is adding far too much code to ovs related to offload? It is handled similar to what vlan is doing for older kernel + in addition it takes care of handling copy + restore skb->protocol since skb_gso_segment relies on it and handle cases for non-gso packets to calculate checksum. I don't understand your comments, have you looked at latest patch? > > Generally speaking the emulation code is handled by skb_gso_segment() > in dev.c in the kernel code outside of OVS. This should mostly work > except that it needs to be able to detect that MPLS requires > emulation. This will be the easiest part to get working and is the > best place to start. However, in order for this code to work on any > kernel before your changes get integrated (i.e. Linux 3.6 at the > earliest) you'll have to emulate it in OVS as well, like we do for > vlans in vport-netdev.c. > >> 2. vlan/mpls tunneling in gre or ip, performance numbers are not good. >> However, using latest git code I tried sending vlan tagged packets on >> gre tunnel and performance is bad as well. I will have to look into it >> further because its not yet clear to me why performance would be bad. > > I think if you get point #1 working correctly then tunneling > offloading should just work. <rk> As i mentioned earlier, can you elaborate your earlier comments? > >> Finally, are performance numbers for OVS published or documented? > > There would be too much variation between machines to be useful for > development. Just run your test on master and compare. <rk> that's what I did for vlan + gre and performance numbers looked bad and hence asked the question _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev