summaryrefslogtreecommitdiffstats
path: root/drivers/net/ibmveth.h
AgeCommit message (Collapse)Author
2005-10-28[PATCH] ibmveth lockless TXSantiago Leon
This patch adds the lockless TX feature to the ibmveth driver. The hypervisor has its own locking so the only change that is necessary is to protect the statistics counters. Signed-off-by: Santiago Leon <santil@us.ibm.com> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-10-28[PATCH] ibmveth fix buffer replenishingSantiago Leon
This patch removes the allocation of RX skb's buffers from a workqueue to be called directly at RX processing time. This change was suggested by Dave Miller when the driver was starving the RX buffers and deadlocking under heavy traffic: > Allocating RX SKBs via tasklet is, IMHO, the worst way to > do it. It is no surprise that there are starvation cases. > > If tasklets or work queues get delayed in any way, you lose, > and it's very easy for a card to catch up with the driver RX'ing > packets very fast, no matter how aggressive you make the > replenishing. By the time you detect that you need to be > "more aggressive" it is already too late. > The only pseudo-reliable way is to allocate at RX processing time. > Signed-off-by: Santiago Leon <santil@us.ibm.com> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-10-28[PATCH] ibmveth fix buffer pool managementSantiago Leon
This patch changes the way the ibmveth driver handles the receive buffers. The old code mallocs and maps all the buffers in the pools regardless of MTU size and it also limits the number of buffer pools to three. This patch makes the driver malloc and map the buffers necessary to support the current MTU. It also changes the hardcoded names of the buffer pool number, size, and elements to arrays to make it easier to change (with the hope of making them runtime parameters in the future). Signed-off-by: Santiago Leon <santil@us.ibm.com> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!