[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM4PR04MB16042515F3D8DD0EF54219A9ECA70@AM4PR04MB1604.eurprd04.prod.outlook.com>
Date: Mon, 7 Nov 2016 16:59:14 +0000
From: Madalin-Cristian Bucur <madalin.bucur@....com>
To: David Miller <davem@...emloft.net>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"oss@...error.net" <oss@...error.net>,
"ppc@...dchasers.com" <ppc@...dchasers.com>,
"joe@...ches.com" <joe@...ches.com>,
"pebolle@...cali.nl" <pebolle@...cali.nl>
Subject: RE: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet
> From: David Miller [mailto:davem@...emloft.net]
> Sent: Monday, November 07, 2016 6:40 PM
>
> From: Madalin-Cristian Bucur <madalin.bucur@....com>
> Date: Mon, 7 Nov 2016 16:32:16 +0000
>
> >> From: David Miller [mailto:davem@...emloft.net]
> >> Sent: Monday, November 07, 2016 5:55 PM
> >>
> >> From: Madalin-Cristian Bucur <madalin.bucur@....com>
> >> Date: Mon, 7 Nov 2016 15:43:26 +0000
> >>
> >> >> From: David Miller [mailto:davem@...emloft.net]
> >> >> Sent: Thursday, November 03, 2016 9:58 PM
> >> >>
> >> >> Why? By clearing this, you disallow an important fundamental way to
> >> >> do performane testing, via pktgen.
> >> >
> >> > The Tx path in DPAA requires one to insert a back-pointer to the skb
> >> > into
> >> > the Tx buffer. On the Tx confirmation path the back-pointer in the
> >> > buffer
> >> > is used to release the skb. If Tx buffer is shared we'd alter the
> >> > back-pointer
> >> > and leak/double free skbs. See also
> >>
> >> Then have your software state store an array of SKB pointers, one for
> each
> >> TX ring entry, just like every other driver does.
> >
> > There is no Tx ring in DPAA. Frames are send out on QMan HW queues
> > towards the FMan for Tx and then received back on Tx confirmation queues
> > for cleanup.
> > Array traversal would for sure cost more than using the back-pointer.
> > Also, we can now process confirmations on a different core than the one
> > doing Tx,
> > we'd have to keep the arrays percpu and force the Tx conf on the same
> > core. Or add locks.
>
> Report back an integer index, like every scsi driver out there which
> completes tagged queued block I/O operations asynchronously. You can
> associate the array with a specific TX confirmation queue.
>From HW? It only gives you back the buffer start address (plus length, etc).
"buff_2_skb()" needs to be solved in SW, expensively using array (lists? As
the number of frames in flight can be large/variable) or cheaply with the back
pointer. The back-pointer approach has its tradeoffs: no shared skbs, imposed
non-zero needed_headroom.
Powered by blists - more mailing lists