Darrell, I think that you are working on some of the specific items that Aaron listed. Can you comment on that?
On Sat, Nov 25, 2017 at 07:37:23PM +0000, Darrell Ball wrote: > Let me clarify some general points. > > 1/ We will not be porting any code from the Linux kernel, whether it be SIP > module code or anything else. > > 2/ Furthermore, we will not be using proprietary code algorithms and other > aspects from the Linux kernel. > > 3/ Furthermore, those people working in, having worked in, or having been > exposed to Netfilter code need to > be careful about any “cross-pollination”, intentional or otherwise. > > 4/ In addition, in general, we don’t think it is necessary to copy the > behavior of the kernel; we look at > each behavior and see if it makes sense or is necessary on its own technical > merits. If we don’t think it > necessary, overly complex, or we have something better, we can omit that > behavior entirely or do it differently. > > Thanks Darrell > > > > On 11/25/17, 9:47 AM, "ovs-dev-boun...@openvswitch.org on behalf of Tiago > Lam" <ovs-dev-boun...@openvswitch.org on behalf of tiago...@gmail.com> wrote: > > Hi Aaron (and all), > > Thank you for your email, I found it to be informative. > > Would you mind elaborating a bit more on point number 5 below? > > With regards to SIP (don't know about SCTP), a module [1] seems to already > exist for the kernel, integrating with Netfilter / conntrack. > > So, in terms of support for SIP in OVS' userspace conntrack (or any other > new > protocol for that matter, but I'm most familiar with SIP), would OVS be > looking for a port, or a "from scratch" implementation? Or what would be > the > preference here? > > Thanks and regards, > > Tiago. > > [1] > https://urldefense.proofpoint.com/v2/url?u=https-3A__people.netfilter.org_chentschel_docs_sip-2Dconntrack-2Dnat.html&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=FfTX_mff2SgY4OCYC5YbZOO44fljLYgir7rk9fccjRQ&s=Pfb29ck4yGzJEN3CgHQWatvLFA-XFUuMG_UWAKoutN0&e= > > On 11/20/2017 06:21 PM, Aaron Conole wrote: > > (NOTE: This is a resend - I fat-fingered the ovs email. Apologies to > > those who got duplicates). > > > > This email is meant to summarize some of the discussions we had at OvS > > conference. > > > > The interest in the userspace conntrack is heating up. That's a good > > thing, but it means that we'll probably have some growing pains as it > > relates to features and usages. These are the topics and some > > additional information that we came up with. > > > > 1. Making EST state match between linux kernel conntrack and userspace > > conntrack. We will need to make sure that the windows datapath > > conntrack also matches. The issue came down to the distinction about > > whether commit action should also imply that the connection is > > established. > > > > 2. Disabling conntrack helpers 'on by default' in the userspace > > datapath. This represents possible security issue; users will want > > to disable helpers (or enable helpers) at their own discretion. > > One proposed resolution to this is simply disabling the helpers, and > > relying on the 'alg=' specifier in the conntrack action. Complicating > > this solution is existing users who rely on the existing solution - > > specifically those users with the tftp helper and pxe booting in an > > large data center. > > > > 3. Performance analysis deep-dive. We'd like to get input on the > > performance of the userspace conntrack path. There was discussion > > that the performance was suffering - anything here like additional > > tests people have, or data that can be shared is good. The > > development community is interested in knowing what it means. > > > > 4. Hardware offload. What will we need to present from that standpoint? > > Are there counters or other information that software will need to > > expose? What does it mean for the userspace datapath to be aware of > > hardware offload for conntrack? > > > > 5. Additional protocol support and helpers. We think SCTP, and SIP are > > important. Any others? Anyone think this is useful work to do? > > > > Thanks all for the presentations and discussions. > > _______________________________________________ > > dev mailing list > > d...@openvswitch.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=FfTX_mff2SgY4OCYC5YbZOO44fljLYgir7rk9fccjRQ&s=0oFbn_OEVTacCVLYQVealZJQelpkp-hZmBriL5kLV_s&e= > > > _______________________________________________ > dev mailing list > d...@openvswitch.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=FfTX_mff2SgY4OCYC5YbZOO44fljLYgir7rk9fccjRQ&s=0oFbn_OEVTacCVLYQVealZJQelpkp-hZmBriL5kLV_s&e= > > > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev