On Thu, Dec 15, 2011 at 8:27 PM, Eric Dumazet <[email protected]> wrote: > Le jeudi 15 décembre 2011 à 14:22 -0800, Rick Jones a écrit : >> On 12/15/2011 11:00 AM, Eric Dumazet wrote: >> >> Device's work better if the driver proactively manages >> >> stop_queue/wake_queue. >> >> Old devices used TX_BUSY, but newer devices tend to manage the queue >> >> themselves. >> >> >> > >> > Some 'new' drivers like igb can be fooled in case skb is gso segmented ? >> > >> > Because igb_xmit_frame_ring() needs skb_shinfo(skb)->nr_frags + 4 >> > descriptors, igb should stop its queue not at MAX_SKB_FRAGS + 4, but >> > MAX_SKB_FRAGS*4
can you please help me understand the need for MAX_SKB_FRAGS * 4 as the requirement? Currently driver uses logic like in hard_start_tx: hey I just finished a tx, I should stop the qdisc if I don't have room (in tx descriptors) for a worst case transmit skb (MAX_SKB_FRAGS + 4) the next time I'm called. when cleaning from interrupt: My cleanup is done, do I have enough free tx descriptors (should be MAX_SKB_FRAGS + 4) for a worst case transmit? If yes, restart qdisc. I'm missing the jump from the above logic to using MAX_SKB_FRAGS * 4 (== (18 * 4) == 72) as the minimum number of descriptors I need for a worst case TSO. Each descriptor can point to up to 16kB of contiguous memory, typically we use 1 for offload context setup, 1 for skb->data, and 1 for each page. I think we may be overestimating with MAX_SKB_FRAGS + 4, but that should be no big deal. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
