On Wed, Jun 13, 2012 at 9:24 PM, ravi kerur <rke...@gmail.com> wrote: > 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?
<rk> or are you saying that mpls label should be handled in skb as well esp. in ovs_skb_cb such that in future it will be added to upstream kernel skbs and can be used for mpls label offloading in NICs? I haven't taken this approach as its not sure whether it will ever happen? you can ignore it if this is not the case and let me know what you mean by "adding too much code in ovs and how it is related to offload? > >> 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
