From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH v5] rps: Receive Packet Steering Date: Thu, 21 Jan 2010 10:16:21 +0100 Message-ID: <4B581B65.7070109@gmail.com> References: <412e6f7f1001202354g1022bb64rae267a1b19713b8a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Tom Herbert , davem@davemloft.net, netdev@vger.kernel.org To: Changli Gao Return-path: Received: from gw1.cosmosbay.com ([212.99.114.194]:54328 "EHLO gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753204Ab0AUJQ3 (ORCPT ); Thu, 21 Jan 2010 04:16:29 -0500 In-Reply-To: <412e6f7f1001202354g1022bb64rae267a1b19713b8a@mail.gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: Le 21/01/2010 08:54, Changli Gao a =C3=A9crit : > Sometimes, rxhash will be 0 generated. In order to check whether > rxhash is generated or not, a new bit field in sk_buff is needed. Whe= n > rxhash is generated and saved in sk_buff, the bit is set. >=20 > And, I think rxhash should be reserved when calling skb_copy and skb_= clone. >=20 >=20 I disagree A null rxhash should not be generated by a driver, or even if its null, why should we care ? In this very unlikely event, let get_rps_cpu() compute a (non null) has= h. Adding a bit in skb for such low probability event brings nothing but c= omplexity.