From: Ben Greear <greearb@candelatech.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "Vitaly E. Lavrov" <lve@guap.ru>,
netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: [PATCH] veth: remove hardware checksum feature
Date: Wed, 07 Aug 2013 18:54:25 -0700 [thread overview]
Message-ID: <5202FA51.4040906@candelatech.com> (raw)
In-Reply-To: <1375924125.4004.83.camel@edumazet-glaptop>
On 08/07/2013 06:08 PM, Eric Dumazet wrote:
> On Wed, 2013-08-07 at 17:23 -0700, Ben Greear wrote:
>
>> I am receiving the packet into user space by reading veth2
>> using a packet socket, and then writing that packet out to eth6
>> (e100e). As far as I can tell, it reads from veth2 with bad checksum
>> and then goes onto the wire with bad checksum.
>>
>
> Then, when you read the packet socket, you probably have an indication
> that checksum is to be computed or ignored.
My user-space bridge code doesn't know or care about the checksum, it
is just reading a packet from one interface and writing onto another.
>
> Your application breaks because of this.
>> Is it ever valid to *read* a packet with bad checksum though? I thought
>> the bogus bad hw-checksum issue was only on the tx-side as far as sniffing goes?
>
> We have same flags on loopback interface.
>
> So using your application on loopback should break the same ?
I suppose, I have never tried to bridge loopback, and probably won't
try anytime soon.
> I am not saying your application is buggy, maybe we need a helper in
> net/packet/af_packet.c. Please check TP_STATUS_CSUMNOTREADY
>
> This was added 6 years ago in commit 8dc4194474159660
> ("[PACKET]: Add optional checksum computation for recvmsg")
Hmm, I'm using recmmsg, in case that matters. I'm not sure I really
understand that patch well. It looks like it requires user-space changes?
I'd rather not have to deal with calculating checksums just to bridge
two interfaces...if it comes to that, I'd rather just force a disable
of the HW checksum feature using ethtool when my app is configured in
this manner.
Maybe we should just do the csum calc in the kernel if packet is
about to be sent up to user-space via af_packet? I think that
would keep the expected behaviour, and hopefully not loose any of the performance
benefits for cases where the packet never leaves the kernel?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2013-08-08 1:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 17:20 [PATCH] veth: remove hardware checksum feature Vitaly E. Lavrov
2013-07-25 17:59 ` Eric Dumazet
2013-08-08 0:07 ` Ben Greear
2013-08-08 0:12 ` Eric Dumazet
2013-08-08 0:23 ` Ben Greear
2013-08-08 1:08 ` Eric Dumazet
2013-08-08 1:54 ` Ben Greear [this message]
2013-08-08 2:52 ` Eric Dumazet
2013-08-08 19:43 ` Ben Greear
2013-08-08 20:16 ` Eric Dumazet
2013-08-08 22:13 ` Ben Greear
2013-08-08 22:20 ` Ben Greear
2013-08-08 22:22 ` Eric Dumazet
2013-08-08 22:35 ` Ben Greear
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=5202FA51.4040906@candelatech.com \
--to=greearb@candelatech.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=lve@guap.ru \
--cc=netdev@vger.kernel.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 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.