Mailing List Archive

Philip Craig wrote:
> I need the id in ctnetlink events for my application, so here's a
> patch to add it in case this wasn't left out intentionally.
>

It was, we have plans to remove it. What for do you need it
exactly?

Patrick McHardy wrote:
> Philip Craig wrote:
>> I need the id in ctnetlink events for my application, so here's a
>> patch to add it in case this wasn't left out intentionally.
>>
>
> It was, we have plans to remove it. What for do you need it
> exactly?

So it won't be needed for dumping either?

It's just a simple way of matching up events, so that I can log both
start and finish time, as well as the other details.

The alternative is to cache the tuples in userspace and match on them,
but that is significantly more complicated. And caching requires
more memory usage than having an id in the kernel.

Philip Craig wrote:
> Patrick McHardy wrote:
>
>> Philip Craig wrote:
>>
>>> I need the id in ctnetlink events for my application, so here's a
>>> patch to add it in case this wasn't left out intentionally.
>>>
>> It was, we have plans to remove it. What for do you need it
>> exactly?
>
> So it won't be needed for dumping either?

No, I removed that in 2.6.23-rc.

>
> It's just a simple way of matching up events, so that I can log both
> start and finish time, as well as the other details.
>
> The alternative is to cache the tuples in userspace and match on them,
> but that is significantly more complicated. And caching requires
> more memory usage than having an id in the kernel.
>

True, but its quite a waste in the kernel as well when considering
that almost nobody needs this. I was thinking about derriving a
unique ID just for userspace from the conntrack address (in memory).
Its not unique over time, just as tuples aren't, but when combined
with the tuples it should only clash very rarely, and you'll always
get a DESTROY + NEW event before a clash. Would that work for you?

Patrick McHardy wrote:
> True, but its quite a waste in the kernel as well when considering
> that almost nobody needs this. I was thinking about derriving a
> unique ID just for userspace from the conntrack address (in memory).
> Its not unique over time, just as tuples aren't, but when combined
> with the tuples it should only clash very rarely, and you'll always
> get a DESTROY + NEW event before a clash. Would that work for you?

Yes, that should be fine. I've used that previously with an old
linux 2.4 conntrack events patch.