netdev - Re: [Patch net-next v2] net_sched: introduce tracepoint trace_qdisc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMDZJNXKvyXUZy53=CDyQ8RNfNK2_0-arxRWn40LoLOZY5F1UQ@mail.gmail.com>
Date:   Tue, 13 Jul 2021 09:56:51 +0800
From:   Tonghao Zhang <xiangxia.m.yue@...il.com>
To:     Cong Wang <xiyou.wangcong@...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 Mon, Jul 12, 2021 at 12:45 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
>
> On Sun, Jul 11, 2021 at 9:41 PM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
> >
> > On Mon, Jul 12, 2021 at 12:20 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
> > >
> > > On Sun, Jul 11, 2021 at 9:12 PM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
> > > >
> > > > On Mon, Jul 12, 2021 at 12:02 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
> > > > >
> > > > > 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
> > > > no matter where the packet is dropped, we should allow user to know
> > > > whether dropped in the enqueue.  and the
> > > > what the return value.
> > >
> > > Again you can know it by kfree_skb(). And you can not avoid
> > > kfree_skb() no matter how you change enqueue. So, I don't see your
> > No, If I know what value returned for specified qdisc , I can know
> > what happened, not necessarily kfree_skb()
>
> This is wrong. You have to trace dropped packets because you
> need to know when to delete the key (skb address) from the hashtable
> you use to calculate the latency. You save the key on enqueue and
> remove it on both dequeue and kfree_skb, the only difference is you
No, we can set the timestamp or cb in  skb in enqueue and check them in dequeue.
we may not use the hashtable.
If we use hashtable, we still can check the return value, save them to
hashtable or not.
> only need to calculate the timestamp difference for the former.
>
> Thanks.



-- 
Best regards, Tonghao