On Thu, Aug 18, 2005 at 10:48:15AM -0700, Michael Chan wrote:
> Grant, Please see if this patch fixes the problem.
It does! :^)
> It is for the latest tg3 in 2.6.13-rc.
I applied it to tg3 v3.28 because the box happened to have
a working 2.6.12 kernel and v3.28 compiled without pci_ids.h updat
From: "Wael Noureddine" <[EMAIL PROTECTED]>
Subject: Re: [PATCH] TCP Offload (TOE) - Chelsio
Date: Thu, 18 Aug 2005 21:37:07 -0700
> > The is no RFC violated by being "bursty". Show me the RFC where TCP
> > burstiness is "standardized". This is yet another strawman.
>
> You surely know this is
The is no RFC violated by being "bursty". Show me the RFC where TCP
burstiness is "standardized". This is yet another strawman.
You surely know this is a recurring theme in all congestion control RFCs
(RFC2581 in particular),
as well as in the "Known TCP Implementation Problems" RFC2525.
-
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 20:58:39 -0700 (PDT)
> On Thu, 18 Aug 2005, David S. Miller wrote:
>
> > The same performance can be obtained with stateless offloads.
> > You continually ignore this possibility, as if TOE is the only
> > way.
>
> TCP is a state
From: "Wael Noureddine" <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 20:50:17 -0700
> Can you explain why TOE is a hack while stateless offload is not?
No knowledge of TCP internals necessary, that defines a clean
and maintainable barrier between the device and the network
stack. It also allows all
Christoph Lameter wrote:
We may have TOE in $40 network cards. In fact given the way things shape
up there is the possibility that it may become difficult to get NICs
without TOE next year.
People have been saying this every year.
Every year, we go through this argument.
Every year, people
On Thu, 18 Aug 2005, David S. Miller wrote:
> The same performance can be obtained with stateless offloads.
> You continually ignore this possibility, as if TOE is the only
> way.
TCP is a stateful protocol and what can be done with stateless
offloads is very limited.
-
To unsubscribe from this
On Thu, 18 Aug 2005, David S. Miller wrote:
> Wouldn't you rather have a commoditized $40.00USD gigabit network card
> that got TOE level performance? I guess that question's answer depends
> upon whether you have some financial state in a company doing TOE :-)
We may have TOE in $40 network car
Christoph Lameter wrote:
On Thu, 18 Aug 2005, David S. Miller wrote:
And once again it will be "niche", and very far from commodity.
A specialized optimization for a very small and specialized audience,
ie. not appropriate for Linux upstream.
The TOE method will gradually become standard si
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 20:50:18 -0700 (PDT)
> The TOE method will gradually become standard simply because it allows
> performance that cannot be obtained now with existing hardware. And we
> may be at some speed boundary for the hardware given the lim
From: Digital Aryan <[EMAIL PROTECTED]>
Date: Fri, 19 Aug 2005 09:18:45 +0530
> And seeing what has happened during 100Mbit, 1Gbit and 10Gbit it seems
> reqirements for networking are always "one step ahead" and the cpu, memory,
> bus-bandwidth will take time to match the requirements. Had this ev
On Thu, 18 Aug 2005, David S. Miller wrote:
> And once again it will be "niche", and very far from commodity.
> A specialized optimization for a very small and specialized audience,
> ie. not appropriate for Linux upstream.
The TOE method will gradually become standard simply because it allows
p
> With stateless offloading schemes? Absolutely it is possible.
>
> Even without stateless offloading, if it can't be done today, then
> they will soon.
>
> This is what has always happened in the past, people were preaching
> for TOE back when 100Mbit ethernet was "new and fast". But you
> cer
This is what has always happened in the past, people were preaching
for TOE back when 100Mbit ethernet was "new and fast". But you
certainly don't see anyone trying to justify TOE for those link
speeds today. The same will happen for 1Gbit and 10Gbit links
a year or so from now, the cpu, memor
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 20:39:41 -0700 (PDT)
> In that time frame people will have TOEs for even higher speeds.
And once again it will be "niche", and very far from commodity.
A specialized optimization for a very small and specialized audience,
ie. not
On Thu, 18 Aug 2005, David S. Miller wrote:
> This is what has always happened in the past, people were preaching
> for TOE back when 100Mbit ethernet was "new and fast". But you
> certainly don't see anyone trying to justify TOE for those link
> speeds today. The same will happen for 1Gbit and
I finally got around to creating something that has been missing since
BitKeeper disappeared, and something that Andrew has been wanting
from me for a while: an amalgamation of all the netdev branches that
I maintain internally.
First, a bit of background. Most patches I receive are dumped into
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 17:49:09 -0700 (PDT)
> > I am still very much against TOE going into the Linux networking
> > stack. There are ways to obtain TOE's performance without
> > necessitating stateful support in the cards, everything that's
> > worthwh
On Thu, 18 Aug 2005, David S. Miller wrote:
> The point remains that TOE creates an ENORMOUS support burdon
> upon us, and makes bugs harder to field even if we add the
> "TOE Taint" thing.
Simply switch off the TOE to see if its TOE or the OS stack.
TCP is fairly standard though this is a pretty
From: Timur Tabi <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 17:45:13 -0500
> I think a more accurate question would be, "what TCP/IP stack am I
> talking to, today?" You're making it sound as if TOE fundamentally
> changes the entire Linux kernel, when it only affects networking.
Networking is a
Jeff Garzik wrote:
1) RFC compliance differs based on whether you use a TOE NIC, or Linux
software stack. "What Linux am I talking to, today?"
I think a more accurate question would be, "what TCP/IP stack am I talking to, today?"
You're making it sound as if TOE fundamentally changes the ent
On Thu, 18 Aug 2005 14:32:48 -0700 (PDT)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Chris Wedgwood <[EMAIL PROTECTED]>
> Date: Thu, 18 Aug 2005 09:33:58 -0700
>
> > I thought the concensurs here was that because doing reliable atomic
> > updates of 64-bit values isn't possible on some (
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 15:44:57 -0400
> I would lean toward the e100 driver's interpretation. The frames
> are being dropped, but not because of any error in the frame itself.
> For review purposes, I'll include a patch below that moves tg3 and
> e1000
Please pull from the 'upstream-fixes' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the fixes described in the attached diffstat/changelog/patch.
drivers/net/8139cp.c |7 ++
drivers/net/dm9000.c | 52 -
[EMAIL PROTECTED] wrote:
>
> I gets this problem sometimes too.
> Try this two patch in 2.6.13-rc6, and I have attached the log.
> (the log is filtered with | grep -v "last message repeated")
Sorry, the debugging patch in the original email is wrong. Please
try this one instead.
Thanks,
--
Vis
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 21:46:10 +1000
> This patch fixes a false-positive from debug_smp_processor_id().
>
> The processor ID is only used to look up crypto_tfm objects.
> Any processor ID is acceptable here as long as it is one that is
> iterated on by for_ea
From: Chris Wedgwood <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 09:33:58 -0700
> I thought the concensurs here was that because doing reliable atomic
> updates of 64-bit values isn't possible on some (most?) 32-bit
> architectures so we need additional locking to make this work which is
> undesira
From: Anton Blanchard <[EMAIL PROTECTED]>
Date: Fri, 19 Aug 2005 05:08:36 +1000
> Maybe we should instead fire off the blink timer, return immediately
> and stop the blink when our timeout has been exceeded. If the user
> wanted to clear a blink they could then issue another ethtool call with
> a
Hi,
We had a bad ethernet card that wouldnt initialise, so I figured we
could blink all other ethernets in the box to identify the bad one.
I was surprised to find we could only blink one card at a time, the
other ethtool processes were all blocked in D state. It turns out
the ethtool ioctl take
Hello, list!
I gets this problem sometimes too.
Try this two patch in 2.6.13-rc6, and I have attached the log.
(the log is filtered with | grep -v "last message repeated")
The interesting part starts Aug 18 01:12:19, and the end is at Aug 18
02:17:53.
This patched kernel starts boot Aug 18 01:10:
On Wed, 2005-08-17 at 23:35 -0700, Grant Grundler wrote:
> Dave, Michael,
> I was looking at a new problem Matthew Wilcox reported:
> tg3 networking failed on rx8620 IOX Core LAN
>
Grant, Please see if this patch fixes the problem. It is for the latest
tg3 in 2.6.13-rc.
[TG3]: Fix SerDes
On Thu, 2005-08-18 at 12:42 -0600, Eric W. Biederman wrote:
> Khalid Aziz <[EMAIL PROTECTED]> writes:
> > As soon as I have all the issues sorted out with kexec'ing on INIT on
> > ia64, I will post a fully updated kexec patch for ia64. I now have kexec
> > working solid on INIT with e1000 driver an
Khalid Aziz <[EMAIL PROTECTED]> writes:
> On Thu, 2005-06-30 at 17:52 -0600, Eric W. Biederman wrote:
>
> I have found that I can not walk reboot_notifier list in all cases
> before kexec'ing a new kernel. For instance, when handling INIT on ia64,
> we are running in interrupt context and atleast
On Thu, 2005-08-18 at 12:30 -0600, Khalid Aziz wrote:
> On Thu, 2005-06-30 at 17:52 -0600, Eric W. Biederman wrote:
> > Greg KH <[EMAIL PROTECTED]> writes:
> >
> > > On Thu, Jun 30, 2005 at 05:21:45PM -0600, Eric W. Biederman wrote:
> > >> However I have gotten feedback a couple of times that
> >
On Thu, 2005-06-30 at 17:52 -0600, Eric W. Biederman wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>
> > On Thu, Jun 30, 2005 at 05:21:45PM -0600, Eric W. Biederman wrote:
> >> However I have gotten feedback a couple of times that
> >> driver writers tend to prefer using reboot notifiers. In part
This update fixes a few bugs in the spider_net driver, relative to
the version in 2.6.13-rc6-mm1. Please merge the updated driver in the
2.6.14 cycle.
- Prevent PCI posting problems by using synchronous register access
in critical places
- Check return value from firmware device tree functions
-
Andy Fleming wrote:
I've been pointed at commit number
2bf69b5fe90b3246ab50064c5a690a363e8c53e2
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/jgarzik/
netdev-2.6.git;a=commit;h=2bf69b5fe90b3246ab50064c5a690a363e8c53e2
The commit message says:
phy subsystem: more cleanups
- unexp
I've been pointed at commit number
2bf69b5fe90b3246ab50064c5a690a363e8c53e2
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/jgarzik/
netdev-2.6.git;a=commit;h=2bf69b5fe90b3246ab50064c5a690a363e8c53e2
The commit message says:
phy subsystem: more cleanups
- unexport symbols never use
On Thu, Aug 18, 2005 at 09:28:10AM +0200, Sebastian Cla?en wrote:
> in struct net_device_stats all members are defined as unsgined
> long. In time of gigabit ethernet this takes not long to overflow.
It should still take an appreciable amount of time surely? We can
detect those wraps in userspac
Hi Dave:
On Thu, Aug 18, 2005 at 12:23:38PM +1000, Herbert Xu wrote:
> Ken-ichirou MATSUZAWA <[EMAIL PROTECTED]> wrote:
> >
> > It seems that because ipcomp_alloc_tfms() calls smp_processor_id(),
> > but a comment says not need locking. Is this right?
>
> Yes the comment is right. I'll fix it u
[PATCH]
* struct file cleanup : the very large file_ra_state is now allocated only on demand,
using a dedicated "filp_ra_cache" slab.
machines handling lot of sockets or pipes can save about 80 bytes (or 40
bytes on 32bits platforms) per file.
* private_data : The field is moved close to f
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 09:14:47 +0200
> After reading your suggestions, I understand we still need two slabs.
> One (filp_cachep) without the readahead data, the other one
> (filp_ra_cachep) with it.
Correct.
> static inline struct file_ra_state *get_ra_sta
David S. Miller a écrit :
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 03:05:25 +0200
I would just set the ra pointer to a single global structure if the
allocation fails. Then you can avoid all the other checks. It will
slow down things and trash some state, but not fail and no
43 matches
Mail list logo
