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;
Date:   Wed, 16 Feb 2022 16:36:16 +0200 (EET)
From:   =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= <ilpo.jarvinen@linux.intel.com>
To:     "Martinez, Ricardo" <ricardo.martinez@linux.intel.com>
cc:     Netdev <netdev@vger.kernel.org>, linux-wireless@vger.kernel.org,
        kuba@kernel.org, davem@davemloft.net, johannes@sipsolutions.net,
        ryazanov.s.a@gmail.com, loic.poulain@linaro.org,
        m.chetan.kumar@intel.com, chandrashekar.devegowda@intel.com,
        linuxwwan@intel.com, chiranjeevi.rapolu@linux.intel.com,
        haijun.liu@mediatek.com, amir.hanania@intel.com,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        dinesh.sharma@intel.com, eliot.lee@intel.com,
        moises.veleta@intel.com, pierre-louis.bossart@intel.com,
        muralidharan.sethuraman@intel.com, Soumya.Prakash.Mishra@intel.com,
        sreehari.kancharla@intel.com
Subject: Re: [PATCH net-next v4 08/13] net: wwan: t7xx: Add data path
 interface
In-Reply-To: <05b6a2dd-f485-ce4a-d508-e90f9304d016@linux.intel.com>
Message-ID: <92a244ef-eaf8-6e27-aa9-77e8f941b86@linux.intel.com>
References: <20220114010627.21104-1-ricardo.martinez@linux.intel.com> <20220114010627.21104-9-ricardo.martinez@linux.intel.com> <ca592f64-c581-56a8-8d90-5341ebd8932d@linux.intel.com> <05b6a2dd-f485-ce4a-d508-e90f9304d016@linux.intel.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1525069745-1645022185=:9418"
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1525069745-1645022185=:9418
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Tue, 15 Feb 2022, Martinez, Ricardo wrote:
> On 2/8/2022 12:19 AM, Ilpo Järvinen wrote:
> > On Thu, 13 Jan 2022, Ricardo Martinez wrote:
> > 
> > > +/* SKB control buffer indexed values */
> > > +#define TX_CB_NETIF_IDX		0
> > > +#define TX_CB_QTYPE		1
> > > +#define TX_CB_DRB_CNT		2
> > The normal way of storing a struct to skb->cb area is:
> > 
> > struct t7xx_skb_cb {
> > 	u8	netif_idx;
> > 	u8	qtype;
> > 	u8	drb_cnt;
> > };
> > 
> > #define T7XX_SKB_CB(__skb)	((struct t7xx_skb_cb *)&((__skb)->cb[0]))
> > 
> > However, there's only a single txqt/qtype (TXQ_TYPE_DEFAULT) in the
> > patchset? And it seems to me that drb_cnt is a value that could be always
> > derived using t7xx_get_drb_cnt_per_skb() from the skb rather than
> > stored?
> 
> The next iteration will contain t7xx_tx_skb_cb and t7xx_rx_skb_cb structures.

Ah, I didn't even notice the other one. Why differentiate them? There's 
enough space in cb area and netif_idx is in both anyway. (union inside 
struct could be used if short on space and tx/rx differ but it is not 
needed here now.)

> Also, q_number is going to be used instead of qtype.
> 
> Only one queue is used but I think we can keep this code generic as it is
> straight forward (not like the drb_lack case), any thoughts?

I don't mind if you find it useful.


-- 
 i.

--8323329-1525069745-1645022185=:9418--