ACCOUNT target future (pkttables)

ACCOUNT target future (pkttables)

[Carl-Daniel Hailfinger]

Hi,

I'm currently writing an ACCOUNT target for ebtables and I feel really
uncomfortable in duplicating the existing iptables ACCOUNT code, adding
a few tweaks and releasing it as ebtables ACCOUNT target. The tweaks
would be:
- efficient handling of sparsely poulated networks
- accounting by MAC address
- 64bit counters (optional)
- saturated counters (optional)
- choice of what to count (layer 2/3 length, packets, src/dst)

Some time ago, I found notes from a netfilter developer workshop about
future directions (reducing code duplication, switching to pkttables...)
and my work would counteract your plans to reduce code duplication. Is
there any working code using the new framework and does it make sense
for me to write my code only for the new framework (will that be merged
eventually into mainline)?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: ACCOUNT target future (pkttables)

[Patrick McHardy]

Carl-Daniel Hailfinger wrote:
> Hi,
> 
> I'm currently writing an ACCOUNT target for ebtables and I feel really
> uncomfortable in duplicating the existing iptables ACCOUNT code, adding
> a few tweaks and releasing it as ebtables ACCOUNT target. The tweaks
> would be:
> - efficient handling of sparsely poulated networks
> - accounting by MAC address
> - 64bit counters (optional)
> - saturated counters (optional)
> - choice of what to count (layer 2/3 length, packets, src/dst)
> 
> Some time ago, I found notes from a netfilter developer workshop about
> future directions (reducing code duplication, switching to pkttables...)
> and my work would counteract your plans to reduce code duplication. Is
> there any working code using the new framework and does it make sense
> for me to write my code only for the new framework (will that be merged
> eventually into mainline)?

There is none (or almost none, not sure) pkttables code yet. A better
approach than duplicating everything is to split out the core and make
it useable by both modules. BTW, have you looked at the tc action
API? It may be better suited because all traffic passes through it.

Regards
Patrick