Re: [PATCH 1/2] net: tap: track dropped skb via kfree_skb_reason()

[Dongli Zhang]

Hi Eric,

On 2/7/22 8:32 PM, Eric Dumazet wrote:
> On Mon, Feb 7, 2022 at 7:55 PM Dongli Zhang <dongli.zhang@xxxxxxxxxx> wrote:
>>
>> The TAP can be used as vhost-net backend. E.g., the tap_handle_frame() is
>> the interface to forward the skb from TAP to vhost-net/virtio-net.
>>
>> However, there are many "goto drop" in the TAP driver. Therefore, the
>> kfree_skb_reason() is involved at each "goto drop" to help userspace
>> ftrace/ebpf to track the reason for the loss of packets
>>
>> Cc: Joao Martins <joao.m.martins@xxxxxxxxxx>
>> Cc: Joe Jin <joe.jin@xxxxxxxxxx>
>> Signed-off-by: Dongli Zhang <dongli.zhang@xxxxxxxxxx>
>> ---
>>  drivers/net/tap.c          | 30 ++++++++++++++++++++++--------
>>  include/linux/skbuff.h     |  5 +++++
>>  include/trace/events/skb.h |  5 +++++
>>  3 files changed, 32 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/tap.c b/drivers/net/tap.c
>> index 8e3a28ba6b28..232572289e63 100644
>> --- a/drivers/net/tap.c
>> +++ b/drivers/net/tap.c
>> @@ -322,6 +322,7 @@ rx_handler_result_t tap_handle_frame(struct sk_buff **pskb)
>>         struct tap_dev *tap;
>>         struct tap_queue *q;
>>         netdev_features_t features = TAP_FEATURES;
>> +       int drop_reason = SKB_DROP_REASON_NOT_SPECIFIED;
>>
>>         tap = tap_dev_get_rcu(dev);
>>         if (!tap)
>> @@ -343,12 +344,16 @@ rx_handler_result_t tap_handle_frame(struct sk_buff **pskb)
>>                 struct sk_buff *segs = __skb_gso_segment(skb, features, false);
>>                 struct sk_buff *next;
>>
>> -               if (IS_ERR(segs))
>> +               if (IS_ERR(segs)) {
>> +                       drop_reason = SKB_DROP_REASON_SKB_GSO_SEGMENT;
>>                         goto drop;
>> +               }
>>
>>                 if (!segs) {
>> -                       if (ptr_ring_produce(&q->ring, skb))
>> +                       if (ptr_ring_produce(&q->ring, skb)) {
>> +                               drop_reason = SKB_DROP_REASON_PTR_FULL;
> 
> PTR_FULL is strange .... How about FULL_RING, or FULL_QUEUE ?
> 

I will use FULL_RING.

Thank you very much!

Dongli Zhang