[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <92a244ef-eaf8-6e27-aa9-77e8f941b86@linux.intel.com>
Date: Wed, 16 Feb 2022 16:36:16 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: "Martinez, Ricardo" <ricardo.martinez@...ux.intel.com>
cc: Netdev <netdev@...r.kernel.org>, linux-wireless@...r.kernel.org,
kuba@...nel.org, davem@...emloft.net, johannes@...solutions.net,
ryazanov.s.a@...il.com, loic.poulain@...aro.org,
m.chetan.kumar@...el.com, chandrashekar.devegowda@...el.com,
linuxwwan@...el.com, chiranjeevi.rapolu@...ux.intel.com,
haijun.liu@...iatek.com, amir.hanania@...el.com,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
dinesh.sharma@...el.com, eliot.lee@...el.com,
moises.veleta@...el.com, pierre-louis.bossart@...el.com,
muralidharan.sethuraman@...el.com, Soumya.Prakash.Mishra@...el.com,
sreehari.kancharla@...el.com
Subject: Re: [PATCH net-next v4 08/13] net: wwan: t7xx: Add data path
interface
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.
Powered by blists - more mailing lists