[ovs-discuss] Ovs-conntrack code query
joestringer at nicira.com
Fri Oct 9 23:14:40 UTC 2015
I'm hoping to merge the userspace changes into OVS repo very soon, and
I'm working on a kernel backport for the OVS out-of-tree module in the
background. In terms of kernel releases, linux-4.3 will introduce the
On 9 October 2015 at 06:36, John Hurley <john.hurley at netronome.com> wrote:
> Hi Joe,
> Thanks for the reply.
> I have found the updated code and can now see that template insertion no
> longer occurs and that there is a clear delete.
> This makes much more sense to me now!
> On a side note, is there any update on when conntrack will be merged into
> the main branch and/or kernel distributions?
> On Thu, Oct 8, 2015 at 6:59 PM, Joe Stringer <joestringer at nicira.com> wrote:
>> On 8 October 2015 at 08:25, John Hurley <john.hurley at netronome.com> wrote:
>> > Hi,
>> > Recently I have been looking at the ovs-conntrack branch.
>> > I am interested in the use of netfilter conntrack templates within the
>> > kernel for storing rule information that can then be linked to the
>> > packet
>> > skb and in turn used when passed to the nf_conntrack kernel module.
>> > I notice that a new template is created when a new rule is added to the
>> > kernel with nf_conntrack_alloc and nf_conntrack_tmpl_insert
>> > (conntrack.c/ovs_ct_copy_action).
>> > However, I do not see anywhere in the code that removes template even
>> > when
>> > the rule itself is expired.
>> > Looking at the source code for the nf functions above it appears that
>> > they
>> > set up a timeout to trigger deletion but do not start the timer
>> > (nf_conntrack_confirm sets this).
>> > Am I missing something in the code for handling the cleanup of this
>> > memory
>> > or is there a possible memory leak here?
>> > The ovs-conntrack version I am using was taken from the tip of the
>> > branch in
>> > mid September.
>> Hi John, appreciate the report.
>> If you look at the latest net-next version of this code, the templates
>> are no longer being inserted. ovs_ct_free_action() should handle
>> freeing the template itself. This will be the behaviour that
>> eventually makes it back into the OVS tree kernel module backport.
>> Does that satisfy your concerns?
More information about the discuss