Thread (7 messages) flat view 7 messages, 3 authors, 2017-01-23

Re: Question about veth_xmit()

From: Eric Dumazet <hidden>
Date: 2017-01-23 19:07:44

On Mon, 2017-01-23 at 10:46 -0800, Xiangning Yu wrote:
Hi netdev folks,

It looks like we call dev_forward_skb() in veth_xmit(), which calls
netif_rx() eventually.

While netif_rx() will enqueue the skb to the CPU RX backlog before the
actual processing takes place. So, this actually means a TX skb has to
wait some un-related RX skbs to finish. And this will happen twice for
a single ping, because the veth device always works as a pair?

IMHO this might lead to some latency issue under certain workload,
can we change the call to dev_forward_skb() to something like this?

        if (likely(__dev_forward_skb(rcv, skb) == NET_RX_SUCCESS)) {
                local_bh_disable();
                netif_receive_skb(skb);
                local_bh_enable();

Could you please shed some light on this change? And please feel free
to correct my if my understanding is wrong.
How veth would have different latency requirement than loopback device ?

Calling netif_receive_skb() is considered too dangerous here (or from
any ndo_start_xmit()) because of possible kernel stack exhaustion.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help