> 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 buffe
rs. I dont 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: TCP&I
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 pro
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
"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
> > 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
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 chip
"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
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 pame
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
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 times
Terry Lambert writes:
> Jonathan Lemon wrote:
> > >I'm trying to use the TCP&IP 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 s
On Fri, Sep 28, 2001 at 01:01:20 -0700, Terry Lambert wrote:
> Jonathan Lemon wrote:
> > >I'm trying to use the TCP&IP checksum offload capability of the Netgear
> > >GA620 NIC from a SMP FreeBSD 4.2R system running on a typical PIII SBC.
> > >I did enable TCP&IP cksum offload for receive operatio
On Fri, Sep 28, 2001 at 01:01:20AM -0700, Terry Lambert wrote:
> Jonathan Lemon wrote:
> > >I'm trying to use the TCP&IP checksum offload capability of the Netgear
> > >GA620 NIC from a SMP FreeBSD 4.2R system running on a typical PIII SBC.
> > >I did enable TCP&IP cksum offload for receive operat
Julian Elischer 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 gain
Jonathan Lemon wrote:
> >I'm trying to use the TCP&IP checksum offload capability of the Netgear
> >GA620 NIC from a SMP FreeBSD 4.2R system running on a typical PIII SBC.
> >I did enable TCP&IP cksum offload for receive operations by setting the
> >if_hwassist flag in the driver /sys/pci/if_ti.c
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 check
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 lo
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
> 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
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.
Tha
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 Unsubscrib
>
> 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 screw
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
>
> 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/gathe
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?
> >
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
>
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 proble
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
> in
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.
>
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
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 th
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
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 th
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, e
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 fra
In article [EMAIL PROTECTED]> you
write:
>Hello,
>I'm trying to use the TCP&IP checksum offload capability of the Netgear
>GA620 NIC from a SMP FreeBSD 4.2R system running on a typical PIII SBC.
>I did enable TCP&IP cksum offload for receive operations by setting the
>if_hwassist flag in the dr
Hello,
I'm trying to use the TCP&IP checksum offload capability of the Netgear
GA620 NIC from a SMP FreeBSD 4.2R system running on a typical PIII SBC.
I did enable TCP&IP cksum offload for receive operations by setting the
if_hwassist flag in the driver /sys/pci/if_ti.c and verified that it is
38 matches
Mail list logo
