On 2020-07-08 07:50, Christoph Hellwig wrote:
On Mon, Jun 29, 2020 at 04:41:16PM +0100, Robin Murphy wrote:
On 2020-06-28 18:16, Bj�rn T�pel wrote:
On 2020-06-27 09:04, Christoph Hellwig wrote:
On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote:
Given there is roughly a ~5 w
On Wed, Jul 08, 2020 at 07:57:23AM +, Song Bao Hua (Barry Song) wrote:
> > int dma_map_batch_start(struct device *dev, size_t rounded_len,
> > enum dma_data_direction dir, unsigned long attrs, dma_addr_t *addr);
> > int dma_map_batch_add(struct device *dev, dma_addr_t *addr, struct page
> >
lanox.com;
> konrad.w...@oracle.com; jonathan.le...@gmail.com;
> linux-ker...@vger.kernel.org; io...@lists.linux-foundation.org;
> netdev@vger.kernel.org; b...@vger.kernel.org; da...@davemloft.net;
> magnus.karls...@intel.com
> Subject: Re: [PATCH net] xsk: remove cheap_dma optimization
>
On Mon, Jun 29, 2020 at 04:41:16PM +0100, Robin Murphy wrote:
> On 2020-06-28 18:16, Björn Töpel wrote:
>>
>> On 2020-06-27 09:04, Christoph Hellwig wrote:
>>> On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote:
Given there is roughly a ~5 weeks window at max where this removal co
On 2020-06-29 17:41, Robin Murphy wrote:
On 2020-06-28 18:16, Björn Töpel wrote:
[...]>
Somewhat related to the DMA API; It would have performance benefits for
AF_XDP if the DMA range of the mapped memory was linear, i.e. by IOMMU
utilization. I've started hacking a thing a little bit, but it w
On 6/30/20 7:07 AM, Christoph Hellwig wrote:
On Mon, Jun 29, 2020 at 05:18:38PM +0200, Daniel Borkmann wrote:
On 6/29/20 5:10 PM, Björn Töpel wrote:
On 2020-06-29 15:52, Daniel Borkmann wrote:
Ok, fair enough, please work with DMA folks to get this properly integrated and
restored then. Appli
On Mon, Jun 29, 2020 at 05:18:38PM +0200, Daniel Borkmann wrote:
> On 6/29/20 5:10 PM, Björn Töpel wrote:
>> On 2020-06-29 15:52, Daniel Borkmann wrote:
>>>
>>> Ok, fair enough, please work with DMA folks to get this properly integrated
>>> and
>>> restored then. Applied, thanks!
>>
>> Daniel, you
On 6/29/20 5:10 PM, Björn Töpel wrote:
On 2020-06-29 15:52, Daniel Borkmann wrote:
Ok, fair enough, please work with DMA folks to get this properly integrated and
restored then. Applied, thanks!
Daniel, you were too quick! Please revert this one; Christoph just submitted a
4-patch-series tha
On 2020-06-28 18:16, Björn Töpel wrote:
On 2020-06-27 09:04, Christoph Hellwig wrote:
On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote:
Given there is roughly a ~5 weeks window at max where this removal could
still be applied in the worst case, could we come up with a fix /
pro
On 2020-06-29 15:52, Daniel Borkmann wrote:
Ok, fair enough, please work with DMA folks to get this properly
integrated and
restored then. Applied, thanks!
Daniel, you were too quick! Please revert this one; Christoph just
submitted a 4-patch-series that addresses both the DMA API, and the
On 6/28/20 7:16 PM, Björn Töpel wrote:
On 2020-06-27 09:04, Christoph Hellwig wrote:
On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote:
Given there is roughly a ~5 weeks window at max where this removal could
still be applied in the worst case, could we come up with a fix / propos
On 2020-06-29 17:18, Daniel Borkmann wrote:
Nice, tossed from bpf tree then! (Looks like it didn't land on the bpf
list yet,
but seems other mails are currently stuck as well on vger. I presume it
will be
routed to Linus via Christoph?)
Thanks!
Christoph (according to the other mail) was O
On 2020-06-27 09:04, Christoph Hellwig wrote:
On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote:
Given there is roughly a ~5 weeks window at max where this removal could
still be applied in the worst case, could we come up with a fix / proposal
first that moves this into the DMA
On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote:
> Given there is roughly a ~5 weeks window at max where this removal could
> still be applied in the worst case, could we come up with a fix / proposal
> first that moves this into the DMA mapping core? If there is something that
> ca
On 6/26/20 3:43 PM, Björn Töpel wrote:
From: Björn Töpel
When the AF_XDP buffer allocation API was introduced it had an
optimization, "cheap_dma". The idea was that when the umem was DMA
mapped, the pool also checked whether the mapping required a
synchronization (CPU to device, and vice versa)
On Fri, Jun 26, 2020 at 03:43:58PM +0200, Björn Töpel wrote:
> From: Björn Töpel
>
> When the AF_XDP buffer allocation API was introduced it had an
> optimization, "cheap_dma". The idea was that when the umem was DMA
> mapped, the pool also checked whether the mapping required a
> synchronization
16 matches
Mail list logo
