All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Jonathan Lemon <jonathan.lemon@gmail.com>
Cc: Lorenzo Bianconi <lorenzo@kernel.org>,
	netdev@vger.kernel.org, lorenzo.bianconi@redhat.com,
	davem@davemloft.net, thomas.petazzoni@bootlin.com,
	brouer@redhat.com, matteo.croce@redhat.com
Subject: Re: [PATCH net-next 2/3] net: page_pool: add the possibility to sync DMA memory for non-coherent devices
Date: Fri, 15 Nov 2019 09:17:03 +0200	[thread overview]
Message-ID: <20191115071703.GB99458@apalos.home> (raw)
In-Reply-To: <ECC7645D-082A-4590-9339-C45949E10C4D@gmail.com>

Hi Jonathan, 

> 
[...]
> > For the skb reserved queues, this depends on the 'anything'. If the rest
> > of the
> > layers touch (or rather write) into that area, then we'll again gave to
> > sync.
> > If we know that the data has not been altered though, we can hand them
> > back to
> > the device skipping that sync right?
> 
> Sure, but this is also true for eBPF programs.  How would the driver know
> that
> the data has not been altered / compacted by the upper layers?

I haven't looked that up in detail. I was just explaining the reasoning behind
picking a u8 instead of a flag. As Jesper pointed we can get the same result by
using len = 0, so i am fine with the proposed change.

Thanks
/Ilias
> -- 
> Jonathan

  parent reply	other threads:[~2019-11-15  7:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-10 12:09 [PATCH net-next 0/3] add DMA sync capability to page_pool API Lorenzo Bianconi
2019-11-10 12:09 ` [PATCH net-next 1/3] net: mvneta: rely on page_pool_recycle_direct in mvneta_run_xdp Lorenzo Bianconi
2019-11-10 12:09 ` [PATCH net-next 2/3] net: page_pool: add the possibility to sync DMA memory for non-coherent devices Lorenzo Bianconi
2019-11-11 16:48   ` Jesper Dangaard Brouer
2019-11-11 19:11     ` Lorenzo Bianconi
2019-11-13  8:29   ` Jesper Dangaard Brouer
2019-11-14 18:48   ` Jonathan Lemon
2019-11-14 18:53     ` Ilias Apalodimas
2019-11-14 20:27       ` Jonathan Lemon
2019-11-14 20:42         ` Ilias Apalodimas
2019-11-14 21:04           ` Jonathan Lemon
2019-11-14 21:43             ` Jesper Dangaard Brouer
2019-11-15  7:05               ` Ilias Apalodimas
2019-11-15  7:49                 ` Lorenzo Bianconi
2019-11-15  8:03                   ` Ilias Apalodimas
2019-11-15 16:47                     ` Jonathan Lemon
2019-11-15 16:53                       ` Lorenzo Bianconi
2019-11-15  7:17             ` Ilias Apalodimas [this message]
2019-11-10 12:09 ` [PATCH net-next 3/3] net: mvneta: get rid of huge DMA sync in mvneta_rx_refill Lorenzo Bianconi
2019-11-14 18:14   ` Jonathan Lemon
2019-11-14 18:18     ` Ilias Apalodimas

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=20191115071703.GB99458@apalos.home \
    --to=ilias.apalodimas@linaro.org \
    --cc=brouer@redhat.com \
    --cc=davem@davemloft.net \
    --cc=jonathan.lemon@gmail.com \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=lorenzo@kernel.org \
    --cc=matteo.croce@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    /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.