On 14/07/2020 23:42, David Miller wrote:
> From: Boris Pismenny
> Date: Tue, 14 Jul 2020 10:27:11 +0300
>
>> Why is it the kernel's role to protect against such an error?
> Because the kernel should perform it's task correctly no matter what
> in the world the user does.
>
>> Surely the user that
From: Boris Pismenny
Date: Tue, 14 Jul 2020 10:27:11 +0300
> Why is it the kernel's role to protect against such an error?
Because the kernel should perform it's task correctly no matter what
in the world the user does.
> Surely the user that modifies pagecache data while sending it over
> send
From: Boris Pismenny
Date: Tue, 14 Jul 2020 10:31:25 +0300
> At the time, Dave objected when we presented this on the netdev conference,
> and we didn't want to delay the entire series just to argue this point. It's
> all a matter of timing and priorities. Now we have an ASIC that uses this API,
On Tue, 14 Jul 2020 10:31:25 +0300 Boris Pismenny wrote:
> Now we have an ASIC that uses this API, and I'd like to show the best
> possible outcome, and not the best possible given an arbitrary
> limitation that avoids an error where the user does something
> erroneous.
I would not call correctnes
On 14/07/2020 1:59, Jakub Kicinski wrote:
> On Tue, 14 Jul 2020 01:15:26 +0300 Boris Pismenny wrote:
>> On 13/07/2020 22:05, David Miller wrote:
>>> The TLS signatures are supposed to be even stronger than the protocol
>>> checksum, and therefore we should send out valid ones rather than
>>> incorr
On 14/07/2020 4:02, David Miller wrote:
> From: Boris Pismenny
> Date: Tue, 14 Jul 2020 01:15:26 +0300
>
>> On 13/07/2020 22:05, David Miller wrote:
>>> From: Boris Pismenny
>>> Date: Mon, 13 Jul 2020 10:49:49 +0300
>>>
>>> Why can't the device generate the correct TLS signature when
>>> offloadi
From: Boris Pismenny
Date: Tue, 14 Jul 2020 01:15:26 +0300
> On 13/07/2020 22:05, David Miller wrote:
>> From: Boris Pismenny
>> Date: Mon, 13 Jul 2020 10:49:49 +0300
>>
>> Why can't the device generate the correct TLS signature when
>> offloading? Just like for the protocol checksum, the devic
On Tue, 14 Jul 2020 01:15:26 +0300 Boris Pismenny wrote:
> On 13/07/2020 22:05, David Miller wrote:
> > The TLS signatures are supposed to be even stronger than the protocol
> > checksum, and therefore we should send out valid ones rather than
> > incorrect ones.
>
> Right, but one is on packet
On 13/07/2020 22:05, David Miller wrote:
> From: Boris Pismenny
> Date: Mon, 13 Jul 2020 10:49:49 +0300
>
>> An alternative approach that requires no knobs is to change the
>> current TLS_DEVICE sendfile flow to skip the copy. It is really
>> not necessary to copy the data, as the guarantees it pr
From: Boris Pismenny
Date: Mon, 13 Jul 2020 10:49:49 +0300
> An alternative approach that requires no knobs is to change the
> current TLS_DEVICE sendfile flow to skip the copy. It is really
> not necessary to copy the data, as the guarantees it provides to
> users, namely that users can modify p
On 13/07/2020 1:32, David Miller wrote:
> From: Boris Pismenny
> Date: Sun, 12 Jul 2020 13:44:09 +0300
>
>> This patch adds two configuration knobs to control TLS zerocopy sendfile:
>> 1) socket option named TLS_TX_ZEROCOPY_SENDFILE that enables
>> applications to use zerocopy sendfile on a per-so
Add support for zerocopy sendfile when using TLS device offload.
Before this patch, TLS device offload would copy sendfile data to a
bounce buffer. This can be avoided when the user knows that page cache
data is not modified. For example, when a serving static files.
Removing this copy improves per
12 matches
Mail list logo
