> On Tue, 28 May 2002, Ben Greear wrote:
>>It would not be that expensive..it's just an extra counter that
>>is bumped whenever a pkt is dropped.
>>
>
> True for one counter, but generally when considering per
> socket stats as a feature, you include all the TCP/UDP/I
> stats, and if youre not holding locks, thats probably an
> atomic increment. Pretty soon we're talking actual
> performance and scalability money. (Even if we're not
> in the mindset of saving every cycle wherever possible).
Integer increments are usually pretty cheap. Considering
accuracy is not absolutely needed (imho), then there is no
need to lock or use special atomic increments.
So, I view the performance issue as not that big of a deal. Space
may be a bigger deal, and the /proc interface and/or IOCTLs to read
the counters...
If/when I do implement, I'll be sure to make it a selectable option
in the kernel config process...
Ben
-- Ben Greear <greearb@candelatech.com> <Ben_Greear AT excite.com> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/