All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Bianconi <lorenzo@kernel.org>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: [PATCH v2 net-next] net: socionext: get rid of huge dma sync in netsec_alloc_rx_data
Date: Fri, 10 Jan 2020 20:36:51 +0100	[thread overview]
Message-ID: <20200110193651.GA14384@localhost.localdomain> (raw)
In-Reply-To: <20200110200156.041f063f@carbon>

[-- Attachment #1: Type: text/plain, Size: 3506 bytes --]

> On Fri, 10 Jan 2020 19:19:40 +0100
> Lorenzo Bianconi <lorenzo.bianconi@redhat.com> wrote:
> 
> > > On Fri, 10 Jan 2020 16:34:13 +0100
> > > Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> > >   
> > > > > On Fri, Jan 10, 2020 at 02:57:44PM +0100, Lorenzo Bianconi wrote:    
> > > > > > Socionext driver can run on dma coherent and non-coherent devices.
> > > > > > Get rid of huge dma_sync_single_for_device in netsec_alloc_rx_data since
> > > > > > now the driver can let page_pool API to managed needed DMA sync
> > > > > > 
> > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > > > ---
> > > > > > Changes since v1:
> > > > > > - rely on original frame size for dma sync
> > > > > > ---
> > > > > >  drivers/net/ethernet/socionext/netsec.c | 43 +++++++++++++++----------
> > > > > >  1 file changed, 26 insertions(+), 17 deletions(-)
> > > > > >     
> > > > 
> > > > [...]
> > > >   
> > > > > > @@ -883,6 +881,8 @@ static u32 netsec_xdp_xmit_back(struct netsec_priv *priv, struct xdp_buff *xdp)
> > > > > >  static u32 netsec_run_xdp(struct netsec_priv *priv, struct bpf_prog *prog,
> > > > > >  			  struct xdp_buff *xdp)
> > > > > >  {
> > > > > > +	struct netsec_desc_ring *dring = &priv->desc_ring[NETSEC_RING_RX];
> > > > > > +	unsigned int len = xdp->data_end - xdp->data;    
> > > > > 
> > > > > We need to account for XDP expanding the headers as well here. 
> > > > > So something like max(xdp->data_end(before bpf), xdp->data_end(after bpf)) -
> > > > > xdp->data (original)    
> > > > 
> > > > correct, the corner case that is not covered at the moment is when data_end is
> > > > moved forward by the bpf program. I will fix it in v3. Thx  
> > > 
> > > Maybe we can simplify do:
> > > 
> > >  void *data_start = NETSEC_RXBUF_HEADROOM + xdp->data_hard_start;
> > >  unsigned int len = xdp->data_end - data_start;
> > >   
> > 
> > Hi Jesper,
> > 
> > please correct me if I am wrong but this seems to me the same as v2.
> 
> No, this is v2, where you do:
>    len = xdp->data_end - xdp->data;

I mean in the solution you proposed you set (before running the bpf program):

len = xdp->data_end - data_start
where:
data_start = NETSEC_RXBUF_HEADROOM + xdp->data_hard_start

that is equivalent to what I did in v2 (before running the bpf program):
len = xdp->data_end - xdp->data

since:
xdp->data = xdp->data_hard_start + NETSEC_RXBUF_HEADROOM
(set in netsec_process_rx())

Am I missing something?

> 
> Maybe you mean v1? where you calc len like:
>    len = xdp->data_end - xdp->data_hard_start;
>    
> 
> > The leftover corner case is if xdp->data_end is moved 'forward' by
> > the bpf program (I guess it is possible, right?). In this case we
> > will not sync xdp->data_end(new) - xdp->data_end(old)
> 
> Currently xdp->data_end can only shrink (but I plan to extend it). Yes,
> this corner case is left, but I don't think we need to handle it.  When
> a BPF prog shrink xdp->data_end, then i believe it cannot change that
> part the shunk part any longer.
> 

ack, fine to me.

Regards,
Lorenzo

> 
> > 
> > > The cache-lines that need to be flushed/synced for_device is the area
> > > used by NIC DMA engine.  We know it will always start at a certain
> > > point (given driver configured hardware to this).
> 
> 
> -- 
> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   LinkedIn: http://www.linkedin.com/in/brouer
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2020-01-10 19:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10 13:57 [PATCH v2 net-next] net: socionext: get rid of huge dma sync in netsec_alloc_rx_data Lorenzo Bianconi
2020-01-10 14:56 ` Ilias Apalodimas
2020-01-10 15:34   ` Lorenzo Bianconi
2020-01-10 17:33     ` Jesper Dangaard Brouer
2020-01-10 18:19       ` Lorenzo Bianconi
2020-01-10 19:01         ` Jesper Dangaard Brouer
2020-01-10 19:19           ` Ilias Apalodimas
2020-01-10 19:36           ` Lorenzo Bianconi [this message]
2020-01-13 10:39             ` Ilias Apalodimas
2020-01-14  2:11 ` Jakub Kicinski

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=20200110193651.GA14384@localhost.localdomain \
    --to=lorenzo@kernel.org \
    --cc=brouer@redhat.com \
    --cc=davem@davemloft.net \
    --cc=ilias.apalodimas@linaro.org \
    --cc=lorenzo.bianconi@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.