[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1471473242.29842.45.camel@edumazet-glaptop3.roam.corp.google.com>
Date: Wed, 17 Aug 2016 15:34:02 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: John Fastabend <john.fastabend@...il.com>
Cc: xiyou.wangcong@...il.com, jhs@...atatu.com,
alexei.starovoitov@...il.com, brouer@...hat.com,
john.r.fastabend@...el.com, netdev@...r.kernel.org,
davem@...emloft.net
Subject: Re: [RFC PATCH 01/13] net: sched: allow qdiscs to handle locking
On Wed, 2016-08-17 at 12:33 -0700, John Fastabend wrote:
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 4ce07dc..5db395d 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3076,6 +3076,26 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
> int rc;
>
> qdisc_calculate_pkt_len(skb, q);
> +
> + if (q->flags & TCQ_F_NOLOCK) {
> + if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED, &q->state))) {
> + __qdisc_drop(skb, &to_free);
> + rc = NET_XMIT_DROP;
> + } else if ((q->flags & TCQ_F_CAN_BYPASS) && !qdisc_qlen(q)) {
For a lockless qdisc, do you believe TCQ_F_CAN_BYPASS is still a gain ?
Also !qdisc_qlen(q) looks racy anyway ?
> + qdisc_bstats_cpu_update(q, skb);
> + if (sch_direct_xmit(skb, q, dev, txq, root_lock, true))
> + __qdisc_run(q);
> + rc = NET_XMIT_SUCCESS;
> + } else {
> + rc = q->enqueue(skb, q, &to_free) & NET_XMIT_MASK;
> + __qdisc_run(q);
> + }
> +
> + if (unlikely(to_free))
> + kfree_skb_list(to_free);
> + return rc;
> + }
> +
Powered by blists - more mailing lists