plan to use Jumbo frames at all, and I can reduce the
buffers allocated for them if necessary.
Thanks,
-Srinivas
From: [EMAIL PROTECTED] (Bill Paul)
To: [EMAIL PROTECTED] (Kenneth D. Merry)
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: TCPIP cksum offload on FreeBSD 4.2
Hi,
I'm using the Netgear GA620 Gig ethernet NIC with Tigon II chip.
Do you know if it is possible to increase the buffer size for standard sized
ethernet frames from 512 buffers to say, 1024?
I assume I'd have to modify the firmware and the host driver to accomodate
these buffers. I
On the other hand, the Tigon III
is capable of 960 megabits -- about the wire rate limit --
with normal size packets, if you implement software interrupt
coelescing (which doesn't help, unless you crank the load up
to close to wire speed and/or do more of the stack processing
at
Kenneth D. Merry wrote:
Unfortunately, it can not correctly interoperate with a
number of cards in jumbogram mode, so unless you know the
card on the other end and manually configure it (it can't
negotiate properly), you can't really use jumbograms. Or
you could rewrite the firmware
Bill Paul wrote:
It is possible for a driver
to load a custom image into the NIC's memory which will override the
auto-loaded one, and it's also possible to load a new image into
the EEPROM, however this requires an additional manual on top of
the BCM5700 driver developer's guide as well as
On Sat, Sep 29, 2001 at 21:27:46 -0700, Terry Lambert wrote:
Kenneth D. Merry wrote:
Unfortunately, it can not correctly interoperate with a
number of cards in jumbogram mode, so unless you know the
card on the other end and manually configure it (it can't
negotiate properly), you
On Sat, Sep 29, 2001 at 12:00:59 -0700, Terry Lambert wrote:
Kenneth D. Merry wrote:
[ ... transmit checksum offload ... ]
You've got things confused. I think that may be a limitation of some
SysKonnect boards, but certainly isn't a Tigon limitation.
Yes, it's not Tigon chipset
Kenneth D. Merry wrote:
[ ... transmit checksum offload ... ]
You've got things confused. I think that may be a limitation of some
SysKonnect boards, but certainly isn't a Tigon limitation.
Yes, it's not Tigon chipset specific.
Tigon boards come with 512KB, 1MB, or 2MB (never seen one of
The cool thing I've always wanted to do with these programmable network
adapters is to have them capture timestamps of when packets are received
for high-accuracy latency measurements. The network adapter could
drop a timestamp into some header when it's DMA'ed into the host's
memory.
The
Louis A. Mamakos writes:
Some work I did a year or so ago measured the interrupt response time
latency, and it was pretty impressive at how large and variable it
could be.
louie
Yes. Me too, but with a pamette, not a nic.
Have you read the pci pamette perf paper (Systems
In message [EMAIL PROTECTED], Andrew Gallatin
writes:
Louis A. Mamakos writes:
Some work I did a year or so ago measured the interrupt response time
latency, and it was pretty impressive at how large and variable it
could be.
louie
Yes. Me too, but with a pamette, not a nic.
In message [EMAIL PROTECTED], Louis A. Mamakos
writes:
The paper that someone mentioned earlier in this thread had some
statistics on various classes of errors. In a nutshell, they put
packet sniffers on 4 different networks, and collected traffic. For
each back packet (where the checksum and
On Fri, Sep 28, 2001 at 01:01:20AM -0700, Terry Lambert wrote:
Jonathan Lemon wrote:
I'm trying to use the TCPIP checksum offload capability of the Netgear
GA620 NIC from a SMP FreeBSD 4.2R system running on a typical PIII SBC.
I did enable TCPIP cksum offload for receive operations by
On Fri, Sep 28, 2001 at 01:01:20 -0700, Terry Lambert wrote:
Jonathan Lemon wrote:
I'm trying to use the TCPIP checksum offload capability of the Netgear
GA620 NIC from a SMP FreeBSD 4.2R system running on a typical PIII SBC.
I did enable TCPIP cksum offload for receive operations by
Terry Lambert writes:
Jonathan Lemon wrote:
I'm trying to use the TCPIP checksum offload capability of the Netgear
GA620 NIC from a SMP FreeBSD 4.2R system running on a typical PIII SBC.
..
He didn't say his packet size, either.
To the original poster: if you are sending
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
I just wanted to say that you did a hell of a job with the csum
offload stuff in FreeBSD. FreeBSD is the only OS that I'm aware of
which allows a driver to choose not to handle csum'ing IP frags on
transmit. Having the option to not handle frags
The other type of failure you might not catch are software errors; that
is, where a packet is produced by the network stack and then is
subsequently stomped on by a random store from some other code. Or
a mis-programmed I/O card with scatter/gather capability doesn't pick
up what was intended,
Ronald G Minnich writes:
I have a question on the checksum offloading. Has anyone measured any
incidence of data corruption between the PCI card and memory. In other
words, when you offload checksums the end-to-end checking becomes
card-to-card checking, and the possibility exists that
Louis A. Mamakos writes:
The other type of failure you might not catch are software errors; that
is, where a packet is produced by the network stack and then is
subsequently stomped on by a random store from some other code. Or
a mis-programmed I/O card with scatter/gather capability
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
No, you're missing the point almost entirely. The checksum is not
skipped. It is calculated by the DMA engine based on the data that's
transferred across the I/O bus on the receiver (and / or the sender).
If the data is incorrect as seen by the
It certainly occurs at a rate to worry one. Alan Poston found definite cases
of corruption when doing heavy IDE testing. It varies, motherboard to
motherboard.
On Thu, 27 Sep 2001, Ronald G Minnich wrote:
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
I just wanted to say that you did a
Ronald G Minnich writes:
you still have a potential problem here with variance in chipsets, namely
the case of broken ABORT or other unusual PCI cycle handling (missed word
problem). I agree it's a low probability. But we've seen it, just a week
or two ago on a brand new box.
But
Ron,
This may be of interest...
http://citeseer.nj.nec.com/stone00when.html
When The CRC and TCP Checksum Disagree
Jonathan Stone, Craig Partridge SIGCOMM
-Sandeep
On Thu, 27 Sep 2001, Ronald G Minnich wrote:
I have a question on the checksum offloading. Has anyone measured any
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
At this level, you're basically screwed. A sofware checksum isn't
even an option on other PCI users, like disk controllers. If you
don't trust your PCI chipset, what do you do about things like that?
I'm rather curious -- what was the
Oh, yeah- I forgot about this. Jonathon is a pretty good NetBSD hacker..
On Thu, 27 Sep 2001, Sandeep Joshi wrote:
Ron,
This may be of interest...
http://citeseer.nj.nec.com/stone00when.html
When The CRC and TCP Checksum Disagree
Jonathan Stone, Craig Partridge SIGCOMM
Ronald G Minnich writes:
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
At this level, you're basically screwed. A sofware checksum isn't
even an option on other PCI users, like disk controllers. If you
don't trust your PCI chipset, what do you do about things like that?
I'm
Louis A. Mamakos writes:
The other type of failure you might not catch are software errors; that
is, where a packet is produced by the network stack and then is
subsequently stomped on by a random store from some other code. Or
a mis-programmed I/O card with scatter/gather
Louis A. Mamakos writes:
I was referring to the case on the transmit side where the wrong
data get's gathered up by the DMA engine because of software related
errors. You get a valid checksum, but for the wrong data. You might
have the wrong data because a drive screwed up setting the
Louis A. Mamakos writes:
I was referring to the case on the transmit side where the wrong
data get's gathered up by the DMA engine because of software related
errors. You get a valid checksum, but for the wrong data. You might
have the wrong data because a drive screwed up
Louis A. Mamakos writes:
Folks ought to consider the likelyhood of this class of data
corruption, unlikely as it is, and weigh it along with the impact on
your application, and the differences in performance and loading.
Agreed. Very well said, by the way..
Drew
To Unsubscribe:
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
Geez. All I wanted to do was pat Jonathan on the back for coming up
with what is apparently the most flexible and well though out
mechanism out there.
it's great work. I was mainly curious to see if anyone had measured this
kind of problem.
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
Geez. All I wanted to do was pat Jonathan on the back for coming up
with what is apparently the most flexible and well though out
mechanism out there.
it's great work. I was mainly curious to see if anyone had measured this
kind of
In the last episode (Sep 27), Louis A. Mamakos said:
And I don't disagree with you, it's wonderful work.
What I guess I'm trying to get across is that like any tool, it ought to
be used properly and in an informed way. For instance, you can mount a
file system async or with soft updates,
Dan Nelson wrote:
Something to do would be to enable hardware checksumming on 1/2 your
machines, and compare the bad packet counts at reported by netstat on
the unchanged machines for (say) a 1-month period before and after the
change. That should tell you whether you're gaining or losing
Hello,
I'm trying to use the TCPIP checksum offload capability of the Netgear
GA620 NIC from a SMP FreeBSD 4.2R system running on a typical PIII SBC.
I did enable TCPIP cksum offload for receive operations by setting the
if_hwassist flag in the driver /sys/pci/if_ti.c and verified that it is
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you
write:
Hello,
I'm trying to use the TCPIP checksum offload capability of the Netgear
GA620 NIC from a SMP FreeBSD 4.2R system running on a typical PIII SBC.
I did enable TCPIP cksum offload for receive operations by setting the
36 matches
Mail list logo
