RE: [PATCH 2.6.25 1/1]S2io: Multiqueue network device support implementation
[Ram] I am assuming that this is with regards to msi-x interrupts. We Yes. And avoiding bouncing locks for device state between CPUs. have done away with handling tx completion in the interrupt handler, and are instead handling them in the context of the transmit. The slow path, straggling transmit completions will be handled in the timer context. Ok -- hopefully you don't have bad corner cases from this when the pipe is not fully filled and then causing longer latencies on completion. Old NAPI sometimes suffered from such problems. [Ram] We have hit the driver pretty hard during testing and have not encountered any problems either on the network or host. Ram -Andi -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2.6.25 1/1]S2io: Multiqueue network device support implementation
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Miller Sent: Wednesday, January 23, 2008 11:30 PM From: Andi Kleen [EMAIL PROTECTED] Date: Thu, 24 Jan 2008 08:25:49 +0100 have done away with handling tx completion in the interrupt handler, and are instead handling them in the context of the transmit. The slow path, straggling transmit completions will be handled in the timer context. Ok -- hopefully you don't have bad corner cases from this when the pipe is not fully filled and then causing longer latencies on completion. Old NAPI sometimes suffered from such problems. BTW, such a TX completion timer will stall TCP sockets when the TX queue of the device is partially filled and then sending stops. TX ring SKB liberation really must be done in a very small finite amount of time in order to avoid this problem properly. Deferring it to HZ granular timers doesn't give a quick enough response, especially at high packet rates. [Ram] We could add a lower granular tx completion interrupt instead, to handle all the transmit fifos. But this will be a fall back in the event the completions do not happen in the context of the transmit. Ram -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.25 1/1]S2io: Multiqueue network device support implementation
Sreenivasa Honnur [EMAIL PROTECTED] writes: Multiqueue netwrok device support implementation. - Added a loadable parameter multiq to enable/disable multiqueue support, by default it is disabled. - skb-queue_mapping is not used for queue/fifo selection. FIFO iselection is based on IP-TOS value, 0x0-0xF TOS values are mapped to 8 FIFOs. Standard way to use that would be using skb-priority But I'm surprised you bother with TOS for multi queues at all. TOS isn't a too important mechanism. I would have thought the primary use case would be per CPU TX completion interrupts. With that the queue should be selected based on the the current CPU. -Andi -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2.6.25 1/1]S2io: Multiqueue network device support implementation
Sreenivasa Honnur [EMAIL PROTECTED] writes: Multiqueue netwrok device support implementation. - Added a loadable parameter multiq to enable/disable multiqueue support, by default it is disabled. - skb-queue_mapping is not used for queue/fifo selection. FIFO iselection is based on IP-TOS value, 0x0-0xF TOS values are mapped to 8 FIFOs. Standard way to use that would be using skb-priority [Ram] Thanks. We can use this field to determine the priority. It should simplify the code. But I'm surprised you bother with TOS for multi queues at all. TOS isn't a too important mechanism. [Ram] Agreed TOS is not too important. The purpose of this patch was to add the multiqueue functionality with a feature that can use it. With multiple transmit fifos enabled, a whole new set of features that can be enabled. I would have thought the primary use case would be per CPU TX completion interrupts. With that the queue should be selected based on the the current CPU. [Ram] I am assuming that this is with regards to msi-x interrupts. We have done away with handling tx completion in the interrupt handler, and are instead handling them in the context of the transmit. The slow path, straggling transmit completions will be handled in the timer context. This patch (along with other new features) will be sent soon. Ram -Andi -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.25 1/1]S2io: Multiqueue network device support implementation
[Ram] I am assuming that this is with regards to msi-x interrupts. We Yes. And avoiding bouncing locks for device state between CPUs. have done away with handling tx completion in the interrupt handler, and are instead handling them in the context of the transmit. The slow path, straggling transmit completions will be handled in the timer context. Ok -- hopefully you don't have bad corner cases from this when the pipe is not fully filled and then causing longer latencies on completion. Old NAPI sometimes suffered from such problems. -Andi -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.25 1/1]S2io: Multiqueue network device support implementation
From: Andi Kleen [EMAIL PROTECTED] Date: Thu, 24 Jan 2008 08:25:49 +0100 have done away with handling tx completion in the interrupt handler, and are instead handling them in the context of the transmit. The slow path, straggling transmit completions will be handled in the timer context. Ok -- hopefully you don't have bad corner cases from this when the pipe is not fully filled and then causing longer latencies on completion. Old NAPI sometimes suffered from such problems. BTW, such a TX completion timer will stall TCP sockets when the TX queue of the device is partially filled and then sending stops. TX ring SKB liberation really must be done in a very small finite amount of time in order to avoid this problem properly. Deferring it to HZ granular timers doesn't give a quick enough response, especially at high packet rates. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.25 1/1]S2io: Multiqueue network device support implementation
Sreenivasa Honnur wrote: Multiqueue netwrok device support implementation. - Added a loadable parameter multiq to enable/disable multiqueue support, by default it is disabled. - skb-queue_mapping is not used for queue/fifo selection. FIFO iselection is based on IP-TOS value, 0x0-0xF TOS values are mapped to 8 FIFOs. - Added per FIFO flags FIFO_QUEUE_START and FIFO_QUEUE_STOP. Check this flag for starting and stopping netif queue and update the flags accordingly. - In tx_intr_handler added a check to ensure that we have free TXDs before wak- ing up the queue. - Added helper functions for queue manipulation(start/stop/wakeup) to invoke appropriate netif_ functions. - Calling netif_start/stop for link up/down case respectively. Signed-off-by: Surjit Reang [EMAIL PROTECTED] Signed-off-by: Sreenivasa Honnur [EMAIL PROTECTED] thanks, at a quick glance, the use of the new multi-queue APIs look ok. I'll give it another in-depth look and merge it. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
