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://people.netfilter.org/chentschel/docs/sip-conntrack-nat.html 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 > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
