Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp5362452iob; Mon, 9 May 2022 14:50:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxr1atZ4Wu+HqHOcjz4bEuf0+MkK9bxdffi/VzoVw/L9eamx2lswcZXcKeRKvYVnjHG0guv X-Received: by 2002:a17:906:6a0e:b0:6f5:30c9:7c7d with SMTP id qw14-20020a1709066a0e00b006f530c97c7dmr14667744ejc.63.1652133042006; Mon, 09 May 2022 14:50:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652133042; cv=none; d=google.com; s=arc-20160816; b=OrUoiaKVHqDpFdK9nG6gW2SamRVyopCph5MkJ6uGx5xPGu40LVBpukVKQ/+tL0i0jl fXjx9r0lTFBhouhG8xdU1eocu9c9rJSGtmrKE4WHwlJe6ffeW7TvrBD3V1dh0Q+l8+UN 1L7sV+TkL0MGcoeN6qYHzHUricOAy6qsZmcUpKefHq15ZYPDkp7JsxRiThBN6mqGIqsl 3fAwU9amtHaey1glq35shF33XGhkMGMV0P0H5VHRsQIPKdlbBf3EA1YAWEI1371eCQif M/FGWpwWwlzgxfdFLo3S0kOKVEtUw2znlblaDyAPaCWhCQWt45yyDAd6k7i8RRD3BQ1X xDSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=d9cSuqzflt6WAV6Y98fLv0ri0pVB/1P8EE7/K4E+Vxg=; b=Dc42ZgcV6DCMiKwJTWO6nrg4ClGZSGounedfeqVoO91b7n//yZscvC6R8WAemTsWrp 6hM0Wsr6FXVIHtvdxT/GGOR1+Lkc4pvbAQs9L+BrN5xKpGjshePJ1vOFOxAyVf+ribJR OyrhVdoE5AlOiW7hGHppslds3yDlk/pPenjwrz73SWKBelwCFGfebP8cSCE9d0KD027L woopdwqYLHL2ZIQfg80aiXW/KykBDB+kY7K7X9mOr/l9A1gOCbTwfSwVo9j7KPxpXv1I FQcjRUjyx7oRoPXxGkZ4S9NQ3r3J8eJG2nF+gGl9xjes78/cMRSA+SockB0+j3qaRJuq q5ZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=STMUFLYX; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k5-20020a17090627c500b006f379d6f423si13260143ejc.582.2022.05.09.14.50.22; Mon, 09 May 2022 14:50:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=STMUFLYX; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229678AbiEIVlZ (ORCPT + 69 others); Mon, 9 May 2022 17:41:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229636AbiEIVlY (ORCPT ); Mon, 9 May 2022 17:41:24 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3ED5AAB5C; Mon, 9 May 2022 14:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652132247; x=1683668247; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=bpwLLLksaAjmFbrWqexTl9pq/J50D/MrBAfquLBNJVw=; b=STMUFLYXPv8yXx4vzIdxwVZX4F1yb8qfACH60whZaLa5rsuvAEgELmC6 fvVn1UEdHBd/E5Bb49r3SxKglMrPIt1+UgL6BjoAYc6nHPNj32iCxqLEV 4tej7smh9Z+uUJZkwU0EOJes+PZuAA9XPrK6N2WSLvNf/hJB8B5o16WM/ AIBR4bEbauIuGJvWIrsxrsB5cXkwEB2xnAv+qb0HOGFMcAVRrFnQw8Ms9 GjVMD/Dm/SrHQdXpckYPtus7aOoiM2wmM7EH9uuA3OcJ2ffjxYawOnu9R faoDxmA6EF4gSYeFQTisD3ZL3AHOnvB6mVduGRWlS/soYsqzWXP6ktaBt g==; X-IronPort-AV: E=McAfee;i="6400,9594,10342"; a="294402865" X-IronPort-AV: E=Sophos;i="5.91,212,1647327600"; d="scan'208";a="294402865" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 May 2022 14:37:27 -0700 X-IronPort-AV: E=Sophos;i="5.91,212,1647327600"; d="scan'208";a="602152507" Received: from rmarti10-mobl2.amr.corp.intel.com (HELO [10.209.126.63]) ([10.209.126.63]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 May 2022 14:37:26 -0700 Message-ID: Date: Mon, 9 May 2022 14:37:26 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH net-next v8 02/14] net: skb: introduce skb_data_area_size() Content-Language: en-US To: Jakub Kicinski , Sergey Ryazanov Cc: netdev@vger.kernel.org, linux-wireless@vger.kernel.org, David Miller , Johannes Berg , Loic Poulain , M Chetan Kumar , "Devegowda, Chandrashekar" , Intel Corporation , chiranjeevi.rapolu@linux.intel.com, =?UTF-8?B?SGFpanVuIExpdSAoIOWImOa1t+WGmyk=?= , "Hanania, Amir" , Andy Shevchenko , "Sharma, Dinesh" , "Lee, Eliot" , "Jarvinen, Ilpo Johannes" , "Veleta, Moises" , "Bossart, Pierre-louis" , "Sethuraman, Muralidharan" , "Mishra, Soumya Prakash" , "Kancharla, Sreehari" , "Sahu, Madhusmita" References: <20220506181310.2183829-1-ricardo.martinez@linux.intel.com> <20220506181310.2183829-3-ricardo.martinez@linux.intel.com> <20220509094930.6d5db0f8@kernel.org> <20220509125008.6d1c3b9b@kernel.org> From: "Martinez, Ricardo" In-Reply-To: <20220509125008.6d1c3b9b@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On 5/9/2022 12:50 PM, Jakub Kicinski wrote: > On Mon, 9 May 2022 21:34:58 +0300 Sergey Ryazanov wrote: >>>> +static inline unsigned int skb_data_area_size(struct sk_buff *skb) >>>> +{ >>>> + return skb_end_pointer(skb) - skb->data; >>>> +} >>> Not a great name, skb->data_len is the length of paged data. >>> There is no such thing as "data area", data is just a pointer >>> somewhere into skb->head. >> What name would you recommend for this helper? > We are assuming that skb->data is where we want to start to write > to so we own the skb. If it's a fresh skb skb->data == skb->tail. > If it's not fresh but recycled - skb->data is presumably reset > correctly, and then skb_reset_tail_pointer() has to be called. Either > way we give HW empty skbs, tailroom is an existing concept we can use. > >>> Why do you need this? Why can't you use the size you passed >>> to the dev_alloc_skb() like everyone else? >> It was I who suggested to Ricardo to make this helper a common >> function [1]. So let me begin the discussion, perhaps Ricardo will add >> to my thoughts as the driver author. >> >> There are many other places where authors do the same but without a >> helper function: >> >> [...] >> >> There are at least two reasons to evaluate the linear data size from skb: >> 1) it is difficult to access the same variable that contains a size >> during skb allocation (consider skb in a queue); > Usually all the Rx skbs on the queue are equally sized so no need to > save the length per buffer, but perhaps that's not universally true. > >> 2) you may not have access to an allocation size because a driver does >> not allocate that skb (consider a xmit path). > On Tx you should only map the data that's actually populated, for that > we have skb_headlen(). > >> Eventually you found themself in a position where you need to carry >> additional info along with skb. But, on the other hand, you can simply >> calculate this value from the skb pointers themselves. >> >> 1. https://lore.kernel.org/netdev/CAHNKnsTr3aq1sgHnZQFL7-0uHMp3Wt4PMhVgTMSAiiXT=8p35A@mail.gmail.com/ > Fair enough, I didn't know more drivers are doing this. > > We have two cases: > - for Tx - drivers should use skb_headlen(); > - for Rx - I presume we are either dealing with fresh or correctly > reset skbs, so we can use skb_tailroom(). Thanks for the information, looks like indeed we can avoid the helper in t7xx driver by following those guidelines.