On 11/27/17, 11:31 AM, "Ben Pfaff" <[email protected]> wrote:
Darrell, I think that you are working on some of the specific items that
Aaron listed. Can you comment on that?
“1”: which is day 1 behavior, has been discussed on other threads on the
mailing list for some weeks. I submitted a patch
that would be used, if it were to have been brought in sync. However,
after further discussions, I realize that just
auto-matching the kernel is not a requirement and people share separate
concerns with this approach, in general. Hence,
in this case, we can go with the better technical option and leave the
userspace conntrack EST as is, since everyone recognizes it
is semantically correct. I will update the documentation with suggested
usages. We can always revisit if we find differences
w.r.t. real/proper conntrack pipelines.
“2”: We enabled default handling of ALGs similar to kernels < 4.7 to get more
test coverage.
There was feedback that since some people may deploy soon and get used
to this particular default, that we should
turn off by default sooner than later. That seemed reasonable since I
found it is hard to define “soon” or “some people”,
so I sent a patch to do that now.
“3”: This is my main focus going forward. This work overlaps with the ‘real’
case performance benchmarking/improvements
I am working on.
“5”: Since I scoped SIP before for other reasons, I have a patch related to
some relevant plumbing support;
I would submit that soon, since it is more relevant now.
Darrell
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, "[email protected] on behalf of Tiago
Lam" <[email protected] on behalf of [email protected]> 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
> > [email protected]
> >
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
> [email protected]
>
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
> [email protected]
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=aCBdxDoV6KZcPYkCAZ7-aUf4LfvFEd5w6-XxO8cnzMg&s=DX8H3i14LN87MnIuKRB_7j0VRQH5ANBGbH-Qgfagsp4&e=
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
