From: hiro <23hiro@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] [patch] ethervgbe: add rx checksum offloading
Date: Wed, 7 Dec 2022 20:12:22 +0100 [thread overview]
Message-ID: <CAFSF3XOTKWz8J0bwN9y_ae48WKbX3qZkC=nwq7TSfhRJjcBMtQ@mail.gmail.com> (raw)
In-Reply-To: <CAFSF3XPh8HHM+3_j-6ArUinJByDLpbHscSp39FcUYA6-hhKZ1w@mail.gmail.com>
this netflix guy mentions some important points:
https://www.youtube.com/watch?v=36qZYL5RlgY
e.g. if they don't enable *all* those optimizations there's barely any
benefit. turn one off and performance degrades miserably.
basically you have to use TCP segmentation offload, TCP large receive
offload, some kind of sendfile() thingy, and other stuff that i don't
understand, all in unison, or you basically get nothing at all out of
it.
for us i think it's best we just skip all this badly designed over-complexity.
On 11/20/22, hiro <23hiro@gmail.com> wrote:
> my hunch is also that checksum offloading is not worth it, since we
> don't have any kind of fastpath in our packet forwarding (we memcpy
> every packet).
>
> also, if we did more computationally intensive work on the packet
> data, like aes encryption, i understand why somebody might want to use
> accelerators for that part. but those checksums are dirt-cheap, on any
> CPU.
>
> On 11/19/22, ori@eigenstate.org <ori@eigenstate.org> wrote:
>> Quoth Arne Meyer <meyer.arne83@netcologne.de>:
>>> Is hw offloading something we want? I ask because I think there is
>>> something wrong with ether8169 offloading and I'm working on a patch to
>>> fix or axe this.
>>>
>>
>> if it makes a real difference in performance and isn't too complex, it
>> may
>> be worth it, but I suspect software is more than fast enough for
>> most of the cards we support.
>>
>>
>
next prev parent reply other threads:[~2022-12-07 19:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-11 16:13 Arne Meyer
2022-11-11 17:01 ` hiro
2022-11-11 17:35 ` Arne Meyer
2022-11-19 20:09 ` Arne Meyer
2022-11-19 21:36 ` ori
2022-11-20 12:44 ` hiro
2022-12-07 19:12 ` hiro [this message]
2022-12-08 1:41 ` cinap_lenrek
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='CAFSF3XOTKWz8J0bwN9y_ae48WKbX3qZkC=nwq7TSfhRJjcBMtQ@mail.gmail.com' \
--to=23hiro@gmail.com \
--cc=9front@9front.org \
/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 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).