From: Jacob Keller <jacob.e.keller@intel.com>
To: David Christensen <drc@linux.vnet.ibm.com>,
<shannon.nelson@amd.com>, <brett.creeley@amd.com>,
<drivers@pensando.io>
Cc: <netdev@vger.kernel.org>
Subject: Re: [PATCH] ionic: fix 16bit math issue when PAGE_SIZE >= 64KB
Date: Tue, 12 Sep 2023 14:13:31 -0700 [thread overview]
Message-ID: <37cef70f-e859-23ad-580c-6eefd45c688d@intel.com> (raw)
In-Reply-To: <331b81ab-7a19-0055-088f-d2f595c26303@linux.vnet.ibm.com>
On 9/12/2023 1:48 PM, David Christensen wrote:
>
>
> On 9/11/23 5:14 PM, Jacob Keller wrote:
>>
>>
>> On 9/11/2023 3:22 PM, David Christensen wrote:
>>> The function ionic_rx_fill() uses 16bit math when calculating the
>>> the number of pages required for an RX descriptor given an interface
>>> MTU setting. If the system PAGE_SIZE >= 64KB, the frag_len and
>>> remain_len values will always be 0, causing unnecessary scatter-
>>> gather elements to be assigned to the RX descriptor, up to the
>>> maximum number of scatter-gather elements per descriptor.
>>>
>>> A similar change in ionic_rx_frags() is implemented for symmetry,
>>> but has not been observed as an issue since scatter-gather
>>> elements are not necessary for such larger page sizes.
>>>
>>> Fixes: 4b0a7539a372 ("ionic: implement Rx page reuse")
>>> Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
>>> ---
>>
>> Given this is a bug fix, it should probably have a subject of [PATCH
>> net] or [net] to indicate its targeting the net tree.
>
> Will resend v2 with updated Subject line.
>
>>
>> I'm not sure I follow the logic for frag_len and remain_len always being
>> zero, since typecasting unsigned values truncates the higher bytes
>> (technically its guaranteed by the standard to result in the smallest
>> value congruent modulo 2^16 for a 16bit typecast), so if page_offset was
>> non-zero then the resulting with the typecast should be as well.. but
>> either way its definitely not going to work as desired.
>
> Sorry, tried condensing the explanation too much. I'm not sure how
> frequently buf_info->page_offset is non-zero, but when
> ionic_rx_page_alloc() allocates a new page, as happens during initial
> driver load, it explicitly sets buf_info->page_offset to 0. As a
> result, the remain_len value never decreases from the original frame
> size (e.g. 1522) while frag_len is always calculated as 0 ((min_t(u16,
> 0x5F2, (0x1_0000 - 0) -> 0).
>
Yea that makes sense. When the page offset is zero this definitely
results in a zero value (given that PAGE_SIZE is always a power of 2, so
its congruent value is 0). In either case if PAGE_SIZE > 16bits this
will produce incorrect and unexpected results regardless.
> I'll update the the description in v2.
>
> Dave
Thanks!
-Jake
next prev parent reply other threads:[~2023-09-12 21:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-11 22:22 [PATCH] ionic: fix 16bit math issue when PAGE_SIZE >= 64KB David Christensen
2023-09-12 0:14 ` Jacob Keller
2023-09-12 20:48 ` David Christensen
2023-09-12 21:13 ` Jacob Keller [this message]
2023-09-12 0:24 ` Nelson, Shannon
2023-09-12 22:31 ` David Christensen
2023-09-14 20:28 ` Nelson, Shannon
2023-09-14 20:39 ` Nelson, Shannon
2023-09-14 22:02 ` [PATCH net v2] " David Christensen
2023-09-15 16:55 ` Nelson, Shannon
2023-09-16 10:50 ` patchwork-bot+netdevbpf
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=37cef70f-e859-23ad-580c-6eefd45c688d@intel.com \
--to=jacob.e.keller@intel.com \
--cc=brett.creeley@amd.com \
--cc=drc@linux.vnet.ibm.com \
--cc=drivers@pensando.io \
--cc=netdev@vger.kernel.org \
--cc=shannon.nelson@amd.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.