(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

Reply via email to