From: Maxim Mikityanskiy <maximmi@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Boris Pismenny <borisp@nvidia.com>,
John Fastabend <john.fastabend@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
"David S. Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>, Tariq Toukan <tariqt@nvidia.com>,
Aviad Yehezkel <aviadye@mellanox.com>,
Ilya Lesokhin <ilyal@mellanox.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH net] tls: Skip tls_append_frag on zero copy size
Date: Tue, 26 Apr 2022 18:48:37 +0300 [thread overview]
Message-ID: <6aee5f52-90ec-aa26-bb9c-e13e9e5abfc2@nvidia.com> (raw)
In-Reply-To: <20220422075502.27532722@kernel.org>
On 2022-04-22 17:55, Jakub Kicinski wrote:
> On Thu, 21 Apr 2022 12:47:18 +0300 Maxim Mikityanskiy wrote:
>> On 2022-04-18 17:56, Maxim Mikityanskiy wrote:
>>> On 2022-04-14 13:28, Jakub Kicinski wrote:
>>>> I appreciate you're likely trying to keep the fix minimal but Greg
>>>> always says "fix it right, worry about backports later".
>>>>
>>>> I think we should skip more, we can reorder the mins and if
>>>> min(size, rec space) == 0 then we can skip the allocation as well.
>>>
>>> Sorry, I didn't get the idea. Could you elaborate?
>>>
>>> Reordering the mins:
>>>
>>> copy = min_t(size_t, size, max_open_record_len - record->len);
>>> copy = min_t(size_t, copy, pfrag->size - pfrag->offset);
>>>
>>> I assume by skipping the allocation you mean skipping
>>> tls_do_allocation(), right? Do you suggest to skip it if the result of
>>> the first min_t() is 0?
>>>
>>> record->len used in the first min_t() comes from ctx->open_record, which
>>> either exists or is allocated by tls_do_allocation(). If we move the
>>> copy == 0 check above the tls_do_allocation() call, first we'll have to
>>> check whether ctx->open_record is NULL, which is currently checked by
>>> tls_do_allocation() itself.
>>>
>>> If open_record is not NULL, there isn't much to skip in
>>> tls_do_allocation on copy == 0, the main part is already skipped,
>>> regardless of the value of copy. If open_record is NULL, we can't skip
>>> tls_do_allocation, and copy won't be 0 afterwards.
>>>
>>> To compare, before (pseudocode):
>>>
>>> tls_do_allocation {
>>> if (!ctx->open_record)
>>> ALLOCATE RECORD
>>> Now ctx->open_record is not NULL
>>> if (!sk_page_frag_refill(sk, pfrag))
>>> return -ENOMEM
>>> }
>>> handle errors from tls_do_allocation
>>> copy = min(size, pfrag->size - pfrag->offset)
>>> copy = min(copy, max_open_record_len - ctx->open_record->len)
>>> if (copy)
>>> copy data and append frag
>>>
>>> After:
>>>
>>> if (ctx->open_record) {
>>> copy = min(size, max_open_record_len - ctx->open_record->len)
>>> if (copy) {
>>> // You want to put this part of tls_do_allocation under if (copy)?
>>> if (!sk_page_frag_refill(sk, pfrag))
>>> handle errors
>>> copy = min(copy, pfrag->size - pfrag->offset)
>>> if (copy)
>>> copy data and append frag
>>> }
>>> } else {
>>> ALLOCATE RECORD
>>> if (!sk_page_frag_refill(sk, pfrag))
>>> handle errors
>>> // Have to do this after the allocation anyway.
>>> copy = min(size, max_open_record_len - ctx->open_record->len)
>>> copy = min(copy, pfrag->size - pfrag->offset)
>>> if (copy)
>>> copy data and append frag
>>> }
>>>
>>> Either I totally don't get what you suggested, or it doesn't make sense
>>> to me, because we have +1 branch in the common path when a record is
>>> open and copy is not 0, no changes when there is no record, and more
>>> repeating code hard to compress.
>>>
>>> If I missed your idea, please explain in more details.
>>
>> Jakub, is your comment still relevant after my response? If not, can the
>> patch be merged?
>
> I'd prefer if you refactored the code so tls_push_data() looks more
> natural.
I would be happy to improve the code, but I honestly didn't understand
your idea. My attempt to understand it only made the code worse.
> But the patch is correct so if you don't want to you can
> repost.
OK, I'm resubmitting as is, but in case you find time to elaborate on
your refactoring idea, I'm still open to suggestions.
Thanks.
> Sorry for the delay.
prev parent reply other threads:[~2022-04-26 15:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-13 13:49 [PATCH net] tls: Skip tls_append_frag on zero copy size Maxim Mikityanskiy
2022-04-14 10:28 ` Jakub Kicinski
2022-04-18 14:56 ` Maxim Mikityanskiy
2022-04-21 9:47 ` Maxim Mikityanskiy
2022-04-22 14:55 ` Jakub Kicinski
2022-04-26 15:48 ` Maxim Mikityanskiy [this message]
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=6aee5f52-90ec-aa26-bb9c-e13e9e5abfc2@nvidia.com \
--to=maximmi@nvidia.com \
--cc=aviadye@mellanox.com \
--cc=borisp@nvidia.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=ilyal@mellanox.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=tariqt@nvidia.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.