Ingo Molnar a écrit : > * Eric Dumazet wrote: > > >> Problem is to check available space : >> >> It depends on stack growing UP or DOWN, and depends on caller running >> on process stack, or softirq stack, or even hardirq stack. >> > > ok - i wish such threads were on lkml so that everyone not just the > netdev kabal can read it. It's quite ugly, but if we want to check stack > free space i'd suggest for you to put a stack_can_recurse() call into > arch/x86/kernel/process.c and offer a default __weak implementation in > kernel/fork.c that always returns 0. > > the rule on x86 should be something like this: on 4K stacks and 64-bit > [which have irqstacks] free stack space can go as low as 25%. On 8K > stacks [which doesnt have irqstacks but nests irqs] it should not go > below 50% before falling back to the explicitly queued packet branch. > > this way other pieces of kernel code code can choose between on-stack > fast recursion and explicit iterators. Although i'm not sure i like the > whole concept to begin with ... > > Hi Ingo I took the time to prepare a patch to implement arch_stack_can_recurse() as you suggested. Thank you [PATCH] x86 : arch_stack_can_recurse() introduction Some paths in kernel would like to chose between on-stack fast recursion and explicit iterators. One identified spot is in net loopback driver, where we can avoid netif_rx() and its slowdown if sufficient stack space is available. We introduce a generic arch_stack_can_recurse() which default to a weak function returning 0. On x86 arch, we implement following logic : 32 bits and 4K stacks (separate irq stacks) : can use up to 25% of stack 64 bits, 8K stacks (separate irq stacks) : can use up to 25% of stack 32 bits and 8K stacks (no irq stacks) : can use up to 50% of stack Example of use in drivers/net/loopback.c, function loopback_xmit() if (arch_stack_can_recurse()) netif_receive_skb(skb); /* immediate delivery to stack */ else netif_rx(skb); /* defer to softirq handling */ Signed-off-by: Eric Dumazet