[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKgT0UeBHPTWmQ9SppKrrT=4Gq65gpvSnLxqiFi3DZ3-JW=f4Q@mail.gmail.com>
Date: Wed, 23 Aug 2017 07:51:44 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Michael Chan <michael.chan@...adcom.com>
Cc: "Duyck, Alexander H" <alexander.h.duyck@...el.com>,
"john.fastabend@...il.com" <john.fastabend@...il.com>,
"brouer@...hat.com" <brouer@...hat.com>,
"pstaszewski@...are.pl" <pstaszewski@...are.pl>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"xdp-newbies@...r.kernel.org" <xdp-newbies@...r.kernel.org>,
"andy@...yhouse.net" <andy@...yhouse.net>,
"borkmann@...earbox.net" <borkmann@...earbox.net>
Subject: Re: XDP redirect measurements, gotchas and tracepoints
On Tue, Aug 22, 2017 at 11:59 PM, Michael Chan
<michael.chan@...adcom.com> wrote:
> On Tue, Aug 22, 2017 at 6:06 PM, Alexander Duyck
> <alexander.duyck@...il.com> wrote:
>> On Tue, Aug 22, 2017 at 1:04 PM, Michael Chan <michael.chan@...adcom.com> wrote:
>>>
>>> Right, but it's conceivable to add an API to "return" the buffer to
>>> the input device, right?
>>
>> You could, it is just added complexity. "just free the buffer" in
>> ixgbe usually just amounts to one atomic operation to decrement the
>> total page count since page recycling is already implemented in the
>> driver. You still would have to unmap the buffer regardless of if you
>> were recycling it or not so all you would save is 1.000015259 atomic
>> operations per packet. The fraction is because once every 64K uses we
>> have to bulk update the count on the page.
>>
>
> If the buffer is returned to the input device, the input device can
> keep the DMA mapping. All it needs to do is to dma_sync it back to
> the input device when the buffer is returned.
That is what ixgbe is already doing. The Rx path doesn't free the
page, it just treats it as a bounce buffer and uses the page count to
make certain we don't use a section of the buffer that is already in
use.
- Alex
Powered by blists - more mailing lists