From: Andrew Gallatin <gallatin@myri.com>
To: Jan-Bernd Themann <ossthema@de.ibm.com>
Cc: Thomas Klein <tklein@de.ibm.com>, Jeff Garzik <jeff@garzik.org>,
Jan-Bernd Themann <themann@de.ibm.com>,
netdev <netdev@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-ppc <linuxppc-dev@ozlabs.org>,
Christoph Raisch <raisch@de.ibm.com>,
Marcus Eder <meder@de.ibm.com>,
Stefan Roscher <stefan.roscher@de.ibm.com>,
David Miller <davem@davemloft.net>
Subject: Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
Date: Tue, 31 Jul 2007 09:34:35 -0400 [thread overview]
Message-ID: <46AF3A6B.2040006@myri.com> (raw)
In-Reply-To: <200707311233.31227.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> On Monday 30 July 2007 22:32, Andrew Gallatin wrote:
>> Second, you still need to set skb->ip_summed = CHECKSUM_UNNECESSARY
>> when modified packets are flushed, else the stack will see bad
>> checksums for packets from CHECKSUM_COMPLETE drivers using the
>> skb interface. Fixed in the attached patch.
>
> I thought about it... As we do update the TCP checksum for aggregated
> packets we could add a second ip_summed field in the net_lro_mgr struct
> used for aggregated packets to support HW that does not have any checksum helper
> functionality. These drivers could set this ip_summed field to CHECKSUM_NONE,
> and thus leave the checksum check to the stack. I'm not sure if these old devices benefit
> a lot from LRO. So what do you think?
This might be handy, and it would also fix the problem with
CHECKSUM_PARTIAL drivers using the skb interface by allowing them
to set it to CHECKSUM_UNNECESSARY.
>> Fourth, I did some traffic sniffing to try to figure out what's going
>> on above, and saw tcpdump complain about bad checksums. Have you tried
>> running tcpdump -s 65535 -vvv? Have you also seen bad checksums?
>> I seem to see this for both page- and skb-based versions of the driver.
>>
>
> Hmmm, can't confirm that. For our skb-based version I see
> correct checksums for aggregated packets and for the page-based version as well.
> I used: (tcpdump -i ethX -s 0 -w dump.bin) in combination with ethereal.
> Don't see problems as well with your tcpdump command.
I'm still trying to get a handle on this. It happens both with
page based and skb based receive for me.. I would not be
surprised if I was doing something wrong in myri10ge. But
I don't see it without LRO, or with my LRO. I'll let you
know when I figure it out..
In the meantime, in case you have any insight, I've left a
capture of a small "netcat" transfer of a 64KB file full
of zeros at http://www.myri.com/staff/gallatin/lro/netcat_dump.bz2
Drew
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Gallatin <gallatin@myri.com>
To: Jan-Bernd Themann <ossthema@de.ibm.com>
Cc: netdev <netdev@vger.kernel.org>,
Christoph Raisch <raisch@de.ibm.com>,
Jan-Bernd Themann <themann@de.ibm.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-ppc <linuxppc-dev@ozlabs.org>,
Marcus Eder <meder@de.ibm.com>, Thomas Klein <tklein@de.ibm.com>,
Stefan Roscher <stefan.roscher@de.ibm.com>,
David Miller <davem@davemloft.net>, Jeff Garzik <jeff@garzik.org>
Subject: Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
Date: Tue, 31 Jul 2007 09:34:35 -0400 [thread overview]
Message-ID: <46AF3A6B.2040006@myri.com> (raw)
In-Reply-To: <200707311233.31227.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> On Monday 30 July 2007 22:32, Andrew Gallatin wrote:
>> Second, you still need to set skb->ip_summed = CHECKSUM_UNNECESSARY
>> when modified packets are flushed, else the stack will see bad
>> checksums for packets from CHECKSUM_COMPLETE drivers using the
>> skb interface. Fixed in the attached patch.
>
> I thought about it... As we do update the TCP checksum for aggregated
> packets we could add a second ip_summed field in the net_lro_mgr struct
> used for aggregated packets to support HW that does not have any checksum helper
> functionality. These drivers could set this ip_summed field to CHECKSUM_NONE,
> and thus leave the checksum check to the stack. I'm not sure if these old devices benefit
> a lot from LRO. So what do you think?
This might be handy, and it would also fix the problem with
CHECKSUM_PARTIAL drivers using the skb interface by allowing them
to set it to CHECKSUM_UNNECESSARY.
>> Fourth, I did some traffic sniffing to try to figure out what's going
>> on above, and saw tcpdump complain about bad checksums. Have you tried
>> running tcpdump -s 65535 -vvv? Have you also seen bad checksums?
>> I seem to see this for both page- and skb-based versions of the driver.
>>
>
> Hmmm, can't confirm that. For our skb-based version I see
> correct checksums for aggregated packets and for the page-based version as well.
> I used: (tcpdump -i ethX -s 0 -w dump.bin) in combination with ethereal.
> Don't see problems as well with your tcpdump command.
I'm still trying to get a handle on this. It happens both with
page based and skb based receive for me.. I would not be
surprised if I was doing something wrong in myri10ge. But
I don't see it without LRO, or with my LRO. I'll let you
know when I figure it out..
In the meantime, in case you have any insight, I've left a
capture of a small "netcat" transfer of a 64KB file full
of zeros at http://www.myri.com/staff/gallatin/lro/netcat_dump.bz2
Drew
next prev parent reply other threads:[~2007-07-31 13:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-30 15:24 [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic Jan-Bernd Themann
2007-07-30 15:24 ` Jan-Bernd Themann
2007-07-30 16:17 ` Jeff Garzik
2007-07-30 16:17 ` Jeff Garzik
2007-07-30 22:43 ` David Miller
2007-07-30 22:43 ` David Miller
2007-07-31 0:00 ` Jeff Garzik
2007-07-31 0:00 ` Jeff Garzik
2007-07-30 17:00 ` Linas Vepstas
2007-07-30 17:00 ` Linas Vepstas
2007-07-30 17:43 ` Andrew Gallatin
2007-07-30 17:43 ` Andrew Gallatin
2007-07-30 19:57 ` Stephen Hemminger
2007-07-30 19:57 ` Stephen Hemminger
2007-07-31 3:58 ` Leonid Grossman
2007-07-31 3:58 ` Leonid Grossman
2007-07-30 20:32 ` Andrew Gallatin
2007-07-30 20:32 ` Andrew Gallatin
2007-07-31 10:33 ` Jan-Bernd Themann
2007-07-31 10:33 ` Jan-Bernd Themann
2007-07-31 13:34 ` Andrew Gallatin [this message]
2007-07-31 13:34 ` Andrew Gallatin
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=46AF3A6B.2040006@myri.com \
--to=gallatin@myri.com \
--cc=davem@davemloft.net \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=meder@de.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=ossthema@de.ibm.com \
--cc=raisch@de.ibm.com \
--cc=stefan.roscher@de.ibm.com \
--cc=themann@de.ibm.com \
--cc=tklein@de.ibm.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.