[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180711.205120.1042990490816741459.davem@davemloft.net>
Date: Wed, 11 Jul 2018 20:51:20 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: lirongqing@...du.com
Cc: netdev@...r.kernel.org
Subject: Re: 答复: [PATCH] net: convert gro_count to
bitmask
From: "Li,Rongqing" <lirongqing@...du.com>
Date: Thu, 12 Jul 2018 03:03:51 +0000
>
>
>> -----邮件原件-----
>> 发件人: David Miller [mailto:davem@...emloft.net]
>> 发送时间: 2018年7月12日 10:49
>> 收件人: Li,Rongqing <lirongqing@...du.com>
>> 抄送: netdev@...r.kernel.org
>> 主题: Re: [PATCH] net: convert gro_count to bitmask
>>
>> From: Li RongQing <lirongqing@...du.com>
>> Date: Wed, 11 Jul 2018 17:15:53 +0800
>>
>> > + clear_bit(index, &napi->gro_bitmask);
>>
>> Please don't use atomics here, at least use __clear_bit().
>>
>
> Thanks, this is same as Eric's suggestion.
>
>
>> This is why I did the operations by hand in my version of the patch.
>> Also, if you are going to preempt my patch, at least retain the comment I
>> added around the GRO_HASH_BUCKETS definitions which warns the reader
>> about the limit.
>>
>
> I add BUILD_BUG_ON in netdev_init, so I think we need not to add comment
That's a good compile time check, but the person thinking about editing
the definition doesn't see the limit in the header file nor know why
the limit exists in the first place.
Powered by blists - more mailing lists