> Could you develop some example usage of your extension? Sure. As part of the services we provide, we need to "meter" and/or restrict user traffic. Since we value everything in "megabytes" (a misnomer, actually, since it is really Mibibytes we all speak of), it is much easier to get specific "counters" shown, or, locked as, MiB. Also, for some other types, the traffic is not that big, so a higher "resolution" (i.e. KiB or plain bytes, formatted "nicely") is required and needs to be used. > Yes, this is how our (limited) revision infrastructure works at this > moment. Thank you Pablo. I've given up on my initial idea, which was to create this custom formatting (as well as object creation) at the point where the first iptables statement is created for a particular nfacct object, so I adopted a "plan b", where everything is done via the "nfacct" executable. At the end, I've left iptables alone, and dealt with only the other 3 (core) nfacct components, which do the job quite nicely. If there is interest in what I've done, or anyone from this list finds this useful, here is a full verbatim of what I've done. I am also attaching 3 patches, which cover what I describe below - don't know what is the formal "submission" process, but if some of the Netfilter guys find this useful or wish to expand on what I've done, I'll gladly prepare a formal manual pages/text/notes, if required - just let me know and I'll gladly do that. On the other hand, if you have a bit of critique or find something I've done wrong in the code - please do not hesitate and fire away! The additional functionality I've implemented is to modify the original nfacct components (nfacct executable, libnfnetlink_acct userspace library and nfacct kernel component) to store and display "bytes" and "packets" numbers according to custom format, specified at nfacct object creation time (in other words, during "nfacct add"). The format of "bytes" and "packets" can be independently specified. In other words, the format for showing "packet" numbers can be different from the format used for "bytes" for each individual nfacct object. This (custom) format can be specified at object creation time and takes the following form: nfacct add [[fmt][,fmt]] The first component indicates the format for "packets"; the second, if specified, the format for "bytes", where "fmt" is one the following : def: 00000000000001048576 - default format, as is the case at present 3pl: 1,048,576 - display numbers in "triplets", separated by the "thousand separator" symbol, which is locale-dependent iec: 133.012MiB - display numbers according to the IEC standard (KiB/MiB...) - the suffix is "automatically" determined depending on the value kib: 136,204.288KiB - same as above, but the value and therefore the suffix is "locked" as KiB (kibibytes) mib: 133.012MiB - same as above, but the value and therefore the suffix is "locked" as MiB (mibibytes) gib: 0.130GiB - same as above, but the value and therefore the suffix is "locked" as GiB (gibibytes) tib: 1,008.345TiB - same as above, but the value and therefore the suffix is "locked" as TiB (tebibytes) pib: 1,008.345PiB - same as above, but the value and therefore the suffix is "locked" as PiB (pebibytes) eib: 1,008.345EiB - same as above, but the value and therefore the suffix is "locked" as EiB (exbibytes) si: 139.473MB - display numbers according to the "old" SI standard (KB/MB...) - the suffix is "automatically" determined depending on the value kb: 139,473.191KB - same as above, but the value and therefore the suffix is "locked" as KB (kilobytes) mb: 139.473MB - same as above, but the value and therefore the suffix is "locked" as MB (megabytes) gb: 0.139GB - same as above, but the value and therefore the suffix is "locked" as GB (gigabytes) tb: 1,082.702TB - same as above, but the value and therefore the suffix is "locked" as TB (terabytes) pb: 1,082.702PB - same as above, but the value and therefore the suffix is "locked" as PB (petabytes) eb: 1,082.702EB - same as above, but the value and therefore the suffix is "locked" as EB (exabytes) A note about the "iec" and "si" values: when the "iec" and "si" formats are specified, then the suffixes are determined "automatically", depending on the value of the actual number. For example, a value of 1048576 bytes will be shown as "1.000MiB" (or "1.049MB" respectively, if "si" is used). However, a value of 999999 bytes will be shown as "976.561KiB" (or 999.999KB respectively). Another note on the locale-specific format where the "thousand separator" or "decimal point" symbols are used: these are determined "automatically" and depend on the language settings on the particular machine/server/embedded device on which libnfnetlink_acct userspace library is installed. If that locale cannot be determined, then "en_GB" is used (; Also, if the "fmt" value for a particular component ("packets" or "bytes") is not specified, then the default ("def") is assumed. For example: a) "nfacct add in12 ,mib" is the equivalent of "nfacct add in12 def,mib"; b) "nfacct add in12 3pl," is the equivalent of "nfacct add in12 3pl,def"; and c) "nfacct add in12 ," is the equivalent of "nfacct add in12", as well as "nfacct add in12 def,def"; Another point worth mentioning: if only one "fmt" component is specified, it is assumed that the specified format applies to *both* "bytes" and "packets". In other words: a) "nfacct add in12 3pl" is the equivalent of "nfacct add in12 3pl,3pl" Finally, I've tested these patches against "peculiar" userspace/kernel combination (i.e. old nfacct/libnfnetlink -> new kernel and vice-versa) - they seem to work OK.