From: Ioana Ciornei <ciorneiioana@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Ioana Ciornei <ciorneiioana@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Ioana Ciornei <ioana.ciornei@nxp.com>
Subject: Re: [RFC 6/9] staging: dpaa2-switch: add .ndo_start_xmit() callback
Date: Thu, 5 Nov 2020 10:25:57 +0200 [thread overview]
Message-ID: <20201105082557.c43odnzis35y7khj@skbuf> (raw)
In-Reply-To: <20201105010439.GH933237@lunn.ch>
On Thu, Nov 05, 2020 at 02:04:39AM +0100, Andrew Lunn wrote:
> > +static int dpaa2_switch_build_single_fd(struct ethsw_core *ethsw,
> > + struct sk_buff *skb,
> > + struct dpaa2_fd *fd)
> > +{
> > + struct device *dev = ethsw->dev;
> > + struct sk_buff **skbh;
> > + dma_addr_t addr;
> > + u8 *buff_start;
> > + void *hwa;
> > +
> > + buff_start = PTR_ALIGN(skb->data - DPAA2_SWITCH_TX_DATA_OFFSET -
> > + DPAA2_SWITCH_TX_BUF_ALIGN,
> > + DPAA2_SWITCH_TX_BUF_ALIGN);
> > +
> > + /* Clear FAS to have consistent values for TX confirmation. It is
> > + * located in the first 8 bytes of the buffer's hardware annotation
> > + * area
> > + */
> > + hwa = buff_start + DPAA2_SWITCH_SWA_SIZE;
> > + memset(hwa, 0, 8);
> > +
> > + /* Store a backpointer to the skb at the beginning of the buffer
> > + * (in the private data area) such that we can release it
> > + * on Tx confirm
> > + */
> > + skbh = (struct sk_buff **)buff_start;
> > + *skbh = skb;
>
> Where is the TX confirm which uses this stored pointer. I don't see it
> in this file.
>
The Tx confirm - dpaa2_switch_tx_conf() - is added in patch 5/9.
> It can be expensive to store pointer like this in buffers used for
> DMA.
Yes, it is. But the hardware does not give us any other indication that
a packet was actually sent so that we can move ahead with consuming the
initial skb.
> It has to be flushed out of the cache here as part of the
> send. Then the TX complete needs to invalidate and then read it back
> into the cache. Or you use coherent memory which is just slow.
>
> It can be cheaper to keep a parallel ring in cacheable memory which
> never gets flushed.
I'm afraid I don't really understand your suggestion. In this parallel
ring I would keep the skb pointers of all frames which are in-flight?
Then, when a packet is received on the Tx confirmation queue I would
have to loop over the parallel ring and determine somehow which skb was
this packet initially associated to. Isn't this even more expensive?
Ioana
next prev parent reply other threads:[~2020-11-05 8:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-04 16:57 [RFC 0/9] staging: dpaa2-switch: add support for CPU terminated traffic Ioana Ciornei
2020-11-04 16:57 ` [RFC 1/9] staging: dpaa2-switch: get control interface attributes Ioana Ciornei
2020-11-04 16:57 ` [RFC 2/9] staging: dpaa2-switch: setup buffer pool for control traffic Ioana Ciornei
2020-11-04 16:57 ` [RFC 3/9] staging: dpaa2-switch: setup RX path rings Ioana Ciornei
2020-11-04 16:57 ` [RFC 4/9] staging: dpaa2-switch: setup dpio Ioana Ciornei
2020-11-04 16:57 ` [RFC 5/9] staging: dpaa2-switch: handle Rx path on control interface Ioana Ciornei
2020-11-05 0:45 ` Andrew Lunn
2020-11-05 11:22 ` Ioana Ciornei
2020-11-04 16:57 ` [RFC 6/9] staging: dpaa2-switch: add .ndo_start_xmit() callback Ioana Ciornei
2020-11-04 21:27 ` Vladimir Oltean
2020-11-05 8:11 ` Ioana Ciornei
2020-11-05 1:04 ` Andrew Lunn
2020-11-05 8:25 ` Ioana Ciornei [this message]
2020-11-05 13:45 ` Andrew Lunn
2020-11-05 15:51 ` Ioana Ciornei
2020-11-04 16:57 ` [RFC 7/9] staging: dpaa2-switch: enable the control interface Ioana Ciornei
2020-11-04 16:57 ` [RFC 8/9] staging: dpaa2-switch: properly setup switching domains Ioana Ciornei
2020-11-04 22:08 ` Vladimir Oltean
2020-11-05 10:58 ` Ioana Ciornei
2020-11-04 16:57 ` [RFC 9/9] staging: dpaa2-switch: accept only vlan-aware upper devices Ioana Ciornei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201105082557.c43odnzis35y7khj@skbuf \
--to=ciorneiioana@gmail.com \
--cc=andrew@lunn.ch \
--cc=gregkh@linuxfoundation.org \
--cc=ioana.ciornei@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox