Re: [Patch net-next v2] net_sched: introduce tracepoint trace_qdisc_enqueue()

On Mon, Jul 12, 2021 at 12:20 PM Cong Wang [off-list ref] wrote:

On Sun, Jul 11, 2021 at 9:12 PM Tonghao Zhang [off-list ref] wrote:

quoted

On Mon, Jul 12, 2021 at 12:02 PM Cong Wang [off-list ref] wrote:

quoted

On Sun, Jul 11, 2021 at 8:49 PM Tonghao Zhang [off-list ref] wrote:

quoted

On Mon, Jul 12, 2021 at 11:39 AM Cong Wang [off-list ref] wrote:

quoted

On Sun, Jul 11, 2021 at 8:36 PM Tonghao Zhang [off-list ref] wrote:

quoted

On Mon, Jul 12, 2021 at 11:23 AM Cong Wang [off-list ref] wrote:

quoted

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()

argument of saving kfree_skb() makes any sense here.

Thanks.

-- 
Best regards, Tonghao