[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpWHvY1h-xdUxWk+PhQcMRqSmnDpzxvBLXKh1mARYzQfmg@mail.gmail.com>
Date: Sun, 11 Jul 2021 21:02:44 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Tonghao Zhang <xiangxia.m.yue@...il.com>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>,
Qitao Xu <qitao.xu@...edance.com>,
Cong Wang <cong.wang@...edance.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
Jiri Pirko <jiri@...nulli.us>
Subject: Re: [Patch net-next v2] net_sched: introduce tracepoint trace_qdisc_enqueue()
On Sun, Jul 11, 2021 at 8:49 PM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
>
> On Mon, Jul 12, 2021 at 11:39 AM Cong Wang <xiyou.wangcong@...il.com> wrote:
> >
> > On Sun, Jul 11, 2021 at 8:36 PM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
> > >
> > > On Mon, Jul 12, 2021 at 11:23 AM Cong Wang <xiyou.wangcong@...il.com> wrote:
> > > > Sure, in that case a different packet is dropped, once again you
> > > > can trace it with kfree_skb() if you want. What's the problem?
> > > It's ok, but we can make it better. Yunsheng Lin may have explained why?
> >
> > Why it is better to trace dropped packets both in enqueue and in kfree_skb()?
> I mean we can use one tracepoint to know what happened in the queue,
> not necessary to trace enqueue and kfree_skb()
This is wrong, packets can be dropped for other reasons too, tracing
enqueue is clearly not sufficient even if you trace it unconditionally.
For a quick example, codel drops packets at dequeue rather than
enqueue. ;)
> If so, we must match when the packet is dropped and what packets. if
> we use the return value in trace_qdisc_requeue. It
> is easy to know what happened(when, where, what packets were dropped ).
I am afraid you have to watch the dropped packets.
Thanks.
Powered by blists - more mailing lists