Peter Memishian wrote:
> The problem is that due to what I consider to be hacks to work around
> broken drivers, packets sent by sendfile are queued up freed later
> from a different context.
This is *not* to workaround broken drivers, it's to deal with the fact
that freeing the mblks synchronously means that drivers cannot hold locks
across freemsg(), which is not something we've ever documented as a
I thought the policy, or at least good common sense, was to avoid
holding locks across code that did allocations and frees.
constraint. Further, the asynchronous logic has been improved and I
believe is of comparable performance now.
I haven't tested much since crossbow hit. That reduced performance
so much that its hard to measure other things. However, I find it
hard to believe that the performance could be made comparable
with a hack like this.
Any time you're queuing mblks at roughly 300K enqueue / dequeue
operations per second (assumes 4K pages, and line rate 10GbE)
you're going to see bad performance characteristics -especially
cache misses, which mblks are particularly prone to.
Drew
_______________________________________________
networking-discuss mailing list
[email protected]
