Messages in this thread |  | | Date | Fri, 28 Sep 2001 22:03:46 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [patch] softirq performance fixes, cleanups, 2.4.10. |
| |
On Fri, 28 Sep 2001 kuznet@ms2.inr.ac.ru wrote:
> Why skbs?
because i did not mean to queue 'softirq bits'. the current bitmap is perfectly okay and equivalent to any queued scheme. (i'd say queueing those bits is pretty stupid and only adds overhead. It might make sense once there are more softirqs, but that can wait.)
what i really meant to queue is something much more finegrained: to queue softirq *events*. The ones that get queued by netif_rx into softnet_data[this_cpu]'s input_pkt_queue. We basically have the skb as the 'event context', and we have a number of queues that are used by hardirqs to queue work towards softirq processing.
do you see the whole scope of this approach? It has a number of disadvantages (some of which i outlined in the previous mail), but it also has a number of (i think important) advantages. It's also in fact simpler, once implemented.
but this means that some of the queueing, that is softnet_data & skb pointers now, has to be generalized. netif_rx would use this generic interface to push work towards softirq processing, and the generic softirq engine would use a callback in the event data structure to do actual processing of the event.
eg. a fastroute packet could set its event handler to be a function that does dev_queue_xmit. Other packets could set their event handlers based on their ->dev. The current demultiplexing done in net_rx_action could be done in a more natural way, and eg. fastrouting would not add runtime overhead.
another effect: i think it might be useful to preserve micro-ordering of rx and tx events. It's certainly the best way to get the most out of existing cache footprint, but the downside is that it has a higher 'environment' cache footprint, due to rx and tx functions being called at high frequencies and being intermixed randomly.
> Only "skbs" scares me. :-)
well :)
Ingo
- 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/
|  |