From: Igor Russkikh <firstname.lastname@example.org>
To: Maciej Fijalkowski <email@example.com>
Cc: "Ramsay, Lincoln" <Lincoln.Ramsay@digi.com>,
Florian Westphal <firstname.lastname@example.org>,
"David S. Miller" <email@example.com>,
Jakub Kicinski <firstname.lastname@example.org>, <email@example.com>,
"Dmitry Bogdanov [C]" <firstname.lastname@example.org>
Subject: Re: [EXT] Re: [PATCH v3] aquantia: Remove the build_skb path
Date: Tue, 24 Nov 2020 18:26:29 +0300 [thread overview]
Message-ID: <email@example.com> (raw)
>> Since normal layout is 1400 packets - we do use 2K (half page) for each
> What is 'normal layout is 1400 packets' ? Didn't you mean the 1500 byte
> standard MTU? So this is what you've been trying to tell me - that for
> 1500 byte mtu and 1k HW granularity you need to provide to HW 2k of
> contiguous space, correct?
Sorry for confusion, of course I meant 1500 standard MTU.
>> This way we reuse each allocated page for at least two packets (and
>> skb_shared into the remaining 512b).
> I don't think I follow that. I thought that 2k needs to be exclusive for
> HW and now you're saying that for remaining 512 bytes you can do whatever
> you want.
As soon as we've got packet we know its length. IF its less than 2K minus
skb_shared_info - we put that halfpage directly into skb, and placing the tail
for shared_info. This is what fast path is doing now.
> If that's true then I think you can have build_skb support and I don't see
> that 1k granularity as a limitation.
Thats true, but we can't use build_skb exactly because of the reason Ramsay
discovered. We need extra headspace always.
>> I know many customers do consider AQC chips in near embedded
>> (routers, etc). They really do care about memories. So that could be
> We have a knob that is controlled by ethtool's priv flag so you can change
> the memory model and pull the build_skb out of the picture. Just FYI.
Priv flags are considered harmful today...
But I agree in general we lack support of driver fastpath tuning.
Like changing page order for large jumbos or page reuse logic knobs.
May be devlink params could be considered for this?
>>> This issue would pop up again if this driver would like to support XDP
>>> where 256 byte headroom will have to be provided.
>> Actually it already popped. Thats one of the reasons I'm delaying with
>> patch series for this driver.
>> I think the best tradeoff here would be allocating order 1 or 2 pages
> (i.e. 8K
>> or 16K), and reuse the page for multiple placements of 2K XDP packets:
>> (256+2048)*3 = 6912 (1K overhead for each 3 packets)
>> (256+2048)*7 = 16128 (200b overhead over 7 packets)
> And for XDP_PASS you would use build_skb? Then tailroom needs to be
For efficient PASS - I think both tail and head room should somehow be
reserved. Then yes, build_skb could be used..
next prev parent reply other threads:[~2020-11-24 15:26 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 1:52 [PATCH] aquantia: Reserve space when allocating an SKB Ramsay, Lincoln
2020-11-18 14:02 ` [EXT] " Igor Russkikh
2020-11-19 0:14 ` Ramsay, Lincoln
2020-11-19 5:19 ` Ramsay, Lincoln
2020-11-19 22:01 ` [PATCH] aquantia: Remove the build_skb path Ramsay, Lincoln
2020-11-19 22:07 ` [PATCH v2] " Ramsay, Lincoln
2020-11-19 22:15 ` Florian Westphal
2020-11-19 22:24 ` Ramsay, Lincoln
2020-11-19 22:28 ` Florian Westphal
2020-11-19 22:34 ` [PATCH v3] " Ramsay, Lincoln
2020-11-19 22:49 ` Maciej Fijalkowski
2020-11-20 8:18 ` [EXT] " Igor Russkikh
2020-11-23 19:28 ` Maciej Fijalkowski
2020-11-24 15:26 ` Igor Russkikh [this message]
2020-11-19 22:58 ` Florian Westphal
2020-11-19 23:52 ` [PATCH v4] " Ramsay, Lincoln
2020-11-20 0:17 ` Florian Westphal
2020-11-20 0:23 ` Ramsay, Lincoln
2020-11-21 21:22 ` Jakub Kicinski
2020-11-21 21:23 ` Jakub Kicinski
2020-11-22 22:36 ` Ramsay, Lincoln
2020-11-23 16:42 ` Jakub Kicinski
2020-11-23 21:40 ` [PATCH net v5] " Ramsay, Lincoln
2020-11-24 19:02 ` Jakub Kicinski
2020-11-22 21:55 ` [PATCH v4] " Ramsay, Lincoln
2020-11-20 7:52 ` [EXT] [PATCH] " Igor Russkikh
2020-11-23 4:20 ` Ramsay, Lincoln
2020-11-24 14:29 ` Igor Russkikh
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).