On Fri, Jun 30, 2006 at 04:13:50PM +1000, herbert wrote:
>
> [NET]: Verify gso_type too in gso_segment
Here is a better version that ensures at least one of TCPV4 and TCPV6
is set in tcp_tso_segment.
[NET]: Verify gso_type too in gso_segment
We don't want nasty Xen guests to pass a TCPv6 packet
Hi:
[NET]: Verify gso_type too in gso_segment
We don't want nasty Xen guests to pass a TCPv6 packet in with gso_type set
to TCPv4 or even UDP (or a packet that's both TCP and UDP).
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herber
In article <[EMAIL PROTECTED]> (at Fri, 30 Jun 2006 15:42:09 +1000), Herbert Xu
<[EMAIL PROTECTED]> says:
> [IPV6]: Remove redundant length check on input
>
> We don't need to check skb->len when we're just about to call
> pskb_may_pull since that checks it for us.
>
> Signed-off-by: Herbert Xu
Hello,
I have written a program which gives CPU statistics, then what should i do
for putting this program in to the default kernel? This code is written to
take CPU loading statistics. cpustat; shows the usage load statistic of
your CPU. I Code tested for Intel Processors. After then code will be
Hi:
[IPV6]: Added GSO support for TCPv6
This patch adds GSO support for IPv6 and TCPv6. This is based on a patch
by Ananda Raju <[EMAIL PROTECTED]>. His original description is:
This patch enables TSO over IPv6. Currently Linux network stacks
restricts TSO over IPv6 by clearing
Hi:
[NET]: Generalise TSO-specific bits from skb_setup_caps
This patch generalises the TSO-specific bits from sk_setup_caps by adding
the sk_gso_type member to struct sock. This makes sk_setup_caps generic
so that it can be used by TCPv6 or UFO.
The only catch is that whoever uses this must pro
Hi:
[IPV6]: Added GSO support for TCPv6
This patch adds GSO support for IPv6 and TCPv6.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key:
Hi Dave:
I've added GSO for TCPv6 and updated Ananda's patch. Please note that
the following patches have only been compile-tested.
[IPV6]: Remove redundant length check on input
We don't need to check skb->len when we're just about to call
pskb_may_pull since that checks it for us.
Signed-off
This patch improves the statistics returned from bcm43xx_get_wireless_stats.
The signal level comes
from smoothing the "rssi" value returned by the firmware after it is converted into a dBm value by
the driver. The quality value is a hack derived from the smoothed level and an assumed RX_POWER_M
On Thu, Jun 29, 2006 at 08:15:52PM -0400, jamal wrote:
> On Fri, 2006-30-06 at 09:07 +1200, Sam Vilain wrote:
> > jamal wrote:
>
> > > Makes sense for the host side to have naming convention tied
> > > to the guest. Example as a prefix: guest0-eth0. Would it not
> > > be interesting to have the ho
Starting friday afternoon I'll be away until next Thursday
evening. I'll read email and merge patches intermittantly,
so please be patient during this time :)
I'll try to merge up as much as I can this evening and do
one final networking push to Linus for 2.6.18
This pretty much means all the m
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 18:29:27 -0700
> Use GSO to workaround a rare TSO bug on some chips. This hardware
> bug may be triggered when the TSO header size is greater than 80
> bytes. When this condition is detected in a TSO packet, the driver
> will use GS
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 18:29:36 -0700
> Update version to 3.61.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 18:29:19 -0700
> Clear a bit to enable a hardware fix for some ASF related problem.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied, thanks a lot.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
th
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 18:29:14 -0700
> Add workaround to limit the burst size of rx BDs being DMA'ed to the
> chip. This works around hardware errata on a number of 5750, 5752,
> and 5755 chips.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Ugly b
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 18:29:06 -0700
> Add tg3_netif_stop() when changing the vlgrp (vlan group) pointer. It
> is necessary to quiesce the device before changing that pointer.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Good catch.
Applied, than
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 30 Jun 2006 12:00:44 +1000
> [TCP]: Reset gso_segs if packet is dodgy
>
> I wasn't paranoid enough in verifying GSO information. A bogus gso_segs
> could upset drivers as much as a bogus header would. Let's reset it in
> the per-protocol gso_segme
Dan Williams wrote:
To me, it looks like you're trying to use dBm rather than RSSI here. In
that case, you have to set range->max_qual.level to 0, because the upper
bound of dBm is indeed 0. If you are using negative values _anywhere_
in your code for quality, you're almost certainly using dBm
jamal wrote:
On Thu, 2006-29-06 at 21:11 -0400, Shailabh Nagar wrote:
Andrew Morton wrote:
Shailabh Nagar <[EMAIL PROTECTED]> wrote:
[..]
So if we can detect the silly sustained-high-exit-rate scenario then it
seems to me quite legitimate to do some aggressive data reducti
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>> > inet_bind()
>> > ->sk_dst_get
>> > ->read_lock(&sk->sk_dst_lock)
We are still holding the sock lock when doing sk_dst_get.
>> > > 1 lock held by java_vm/4418:
>> > > #0: (af_family_keys + (sk)->sk_family#4){-+..}, at: []
>> > > tcp_v
Serge E. Hallyn wrote:
> The last one in your diagram confuses me - why foo0:1? I would
> have thought it'd be
>
> host | guest 0 | guest 1 | guest2
> --+---+---+--
> | | | |
> |-> l0
Andrew wrote:
> Nah. Stick it in the same cacheline as tasklist_lock (I'm amazed that
> we've continued to get away with a global lock for that).
Yes - a bit amazing. But no sense compounding the problem now.
We shouldn't be adding global locks/modifiable data in the
fork/exit code path if we c
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
> Sam Vilain wrote:
> > jamal wrote:
> >>> note: personally I'm absolutely not against virtualizing
> >>> the device names so that each guest can have a separate
> >>> name space for devices, but there should be a way to
> >>> 'see' _and_ 'identify' the
On Thu, 29 Jun 2006 19:25:26 -0700
Paul Jackson <[EMAIL PROTECTED]> wrote:
> Andrew wrote:
> > Like, a single message which says "20,000 sub-millisecond-runtime tasks
> > exited in the past second" or something.
>
> System wide accumulation of such data in the exit() code path still
> risks being
Andrew wrote:
> Like, a single message which says "20,000 sub-millisecond-runtime tasks
> exited in the past second" or something.
System wide accumulation of such data in the exit() code path still
risks being a bottleneck, just a bit later on.
I'm more inclined now to look for ways to disable c
On Thu, Jun 29, 2006 at 07:06:51PM -0700, Michael Chan wrote:
>
> Don't we have a bigger problem if it doesn't support ECN with ipv6 TSO?
> We either have to disable ECN when TSO is enabled like we used to for
> ipv4, or provide the gso tcp segmentation for ipv6. Right?
Good point. In that case
On Fri, 2006-06-30 at 10:39 +1000, Herbert Xu wrote:
> BTW, does your card handle ECN correctly? If not then we should change
> the new ECN bit to apply to both TCPv4 and TCPv6 since
>
> 1) We now have a piece of hardware that handles TSO6 and it doesn't do ECN.
> 2) It's quite likely that if the
Hi Dave:
I forgot to verify gso_segs on packets from untrusted sources. In fact
looking around it seems that gso_segs is used by exactly one driver outside
of the TCP stack. In fact it also happens to be a virtual driver: s390/qeth.
Since the only other GSO user we have at the moment -- UFO, do
Eric W. Biederman wrote:
>> Makes sense for the host side to have naming convention tied
>> to the guest. Example as a prefix: guest0-eth0. Would it not
>> be interesting to have the host also manage these interfaces
>> via standard tools like ip or ifconfig etc? i.e if i admin up
>> guest0-eth0, t
On Thu, 2006-29-06 at 21:11 -0400, Shailabh Nagar wrote:
> Andrew Morton wrote:
>
> >Shailabh Nagar <[EMAIL PROTECTED]> wrote:
[..]
> >So if we can detect the silly sustained-high-exit-rate scenario then it
> >seems to me quite legitimate to do some aggressive data reduction on that.
> >Like, a s
Use GSO to workaround a rare TSO bug on some chips. This hardware
bug may be triggered when the TSO header size is greater than 80
bytes. When this condition is detected in a TSO packet, the driver
will use GSO to segment the packet to workaround the hardware bug.
Thanks to Juergen Kreileder <[E
Update version to 3.61.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 63d4b2c..47c96fc 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -69,8 +69,8 @@
#define DRV_MODULE_NAME"tg3"
#define PFX DRV_MODULE_NAME
Add workaround to limit the burst size of rx BDs being DMA'ed to the
chip. This works around hardware errata on a number of 5750, 5752,
and 5755 chips.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 2447fa3..c32655c 100644
--- a/drivers/
Add tg3_netif_stop() when changing the vlgrp (vlan group) pointer. It
is necessary to quiesce the device before changing that pointer.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 35f9316..2447fa3 100644
--- a/drivers/net/tg3.c
+++ b/dr
Clear a bit to enable a hardware fix for some ASF related problem.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index c32655c..2c36e70 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6157,8 +6157,12 @@ static int tg3_reset_hw(struc
On Fri, 2006-30-06 at 02:55 +0200, Thomas Graf wrote:
> * jamal <[EMAIL PROTECTED]> 2006-06-29 20:48
> The point is to avoid having an atomic operation for every packet
> when setting iif in netif_receive_skb(). If it was only for
> mirred nobody would complain I guess.
>
I never intended to pun
On Fri, 2006-30-06 at 02:46 +0200, Thomas Graf wrote:
> * jamal <[EMAIL PROTECTED]> 2006-06-29 20:03
> > On Fri, 2006-30-06 at 01:39 +0200, Thomas Graf wrote:
> > > * jamal <[EMAIL PROTECTED]> 2006-06-29 19:23
> >
> > > > not at all. Let me explain the design intent further below.
> > >
> > > The
Andrew Morton wrote:
Shailabh Nagar <[EMAIL PROTECTED]> wrote:
The rates (or upper bounds) that are being discussed here, as of now,
are 1000 exits/sec/CPU for
1024 CPU systems. That would be roughly 1M exits/system *
248Bytes/message = 248 MB/sec.
I think it's worth differentiating
Shailabh Nagar <[EMAIL PROTECTED]> wrote:
>
> The rates (or upper bounds) that are being discussed here, as of now,
> are 1000 exits/sec/CPU for
> 1024 CPU systems. That would be roughly 1M exits/system *
> 248Bytes/message = 248 MB/sec.
I think it's worth differentiating between burst rates an
* jamal <[EMAIL PROTECTED]> 2006-06-29 20:48
> the ifb references it; only mirred redirects to the ifb at the moment.
> You would need to increment in mirred, no?
> Why do i feel i am missing something? ;->
The point is to avoid having an atomic operation for every packet
when setting iif in netif
On Thu, 2006-29-06 at 17:29 -0700, David Miller wrote:
> From: jamal <[EMAIL PROTECTED]>
> Date: Thu, 29 Jun 2006 20:26:20 -0400
[..]
> > I see; i take it if things were moved around that may change?
>
> Yes.
>
Ok, relief - so i was not totally unreasonable then ;->
> > Can you avoid doing the
* jamal <[EMAIL PROTECTED]> 2006-06-29 20:03
> On Fri, 2006-30-06 at 01:39 +0200, Thomas Graf wrote:
> > * jamal <[EMAIL PROTECTED]> 2006-06-29 19:23
>
> > > not at all. Let me explain the design intent further below.
> >
> > Then let me show you what your code does:
> >
> > [mirred attached to
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 17:44:05 -0700
> Then is prefetching in memcpy really that important to them.
Not really, the thread just blocks while waiting for memory.
On stores they do a cacheline fill optimization similar to
the powerpc.
> Relying on PCI-X device
David Miller wrote:
I'm saying that, we don't need the refcount, just setting
the skb->input_index thing, unless someone actually cares
about the input device.
As long as the packet hits not paths that care about the
SKB input device, no atomic refcounts are taken. It's
just an integer sitting
On Fri, Jun 30, 2006 at 09:32:44AM +1000, Herbert Xu wrote:
>
> > diff -upNr netdev.org/include/linux/skbuff.h
> > netdev.ipv6_tso/include/linux/skbuff.h
> > --- netdev.org/include/linux/skbuff.h 2006-06-27 07:30:36.0 -0700
> > +++ netdev.ipv6_tso/include/linux/skbuff.h 2006-06-27
jamal wrote:
On Thu, 2006-29-06 at 16:01 -0400, Shailabh Nagar wrote:
Jamal,
any thoughts on the flow control capabilities of netlink that apply here
? Usage of the connection is to supply statistics data to userspace.
if you want reliable delivery, then you cant just depend on as
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 17:28:50 -0700
I thought that most PCI controllers (that is to say the things bridging
PCI to the rest of the system) could do prefetching and/or that PCI-X
(if not PCI, no idea about PCI-e) cards could issue mult
From: jamal <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 20:26:20 -0400
> On Thu, 2006-29-06 at 17:12 -0700, David Miller wrote:
> > The objects around it are pointers, which are 64-bit, and thus
> > the 32-bit object gets padded out to 64-bits in the layout of
> > the struct so that the next pointe
On Thu, 2006-29-06 at 17:12 -0700, David Miller wrote:
> From: jamal <[EMAIL PROTECTED]>
> Date: Thu, 29 Jun 2006 20:08:19 -0400
>
> > What am i missing?
> > on 64bit machine, does it not save 32 bits to use an ifindex as opposed
> > to the pointer?
>
> The objects around it are pointers, which a
On Thu, 29 Jun 2006, David Miller wrote:
| From: Bryan O'Sullivan <[EMAIL PROTECTED]>
| Date: Thu, 29 Jun 2006 14:41:29 -0700
|
| > ipath_core-$(CONFIG_X86_64) += ipath_wc_x86_64.o
| > +ipath_core-$(CONFIG_PPC64) += ipath_wc_ppc64.o
|
| Again, don't put these kinds of cpu specific functions
| i
If you bypass the L2 cache, it's pointless because the next
agent (PCI controller, CPU thread, etc.) is going to need the
data in the L2 cache.
It's better in that kind of setup to eat the L2 cache miss overhead in
memcpy since memcpy can usually prefetch and store buffer in order to
absorb some
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 17:28:50 -0700
> I thought that most PCI controllers (that is to say the things bridging
> PCI to the rest of the system) could do prefetching and/or that PCI-X
> (if not PCI, no idea about PCI-e) cards could issue multiple
> transacti
On Fri, 2006-30-06 at 09:07 +1200, Sam Vilain wrote:
> jamal wrote:
> > Makes sense for the host side to have naming convention tied
> > to the guest. Example as a prefix: guest0-eth0. Would it not
> > be interesting to have the host also manage these interfaces
> > via standard tools like ip or i
From: jamal <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 20:08:19 -0400
> What am i missing?
> on 64bit machine, does it not save 32 bits to use an ifindex as opposed
> to the pointer?
The objects around it are pointers, which are 64-bit, and thus
the 32-bit object gets padded out to 64-bits in the
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 30 Jun 2006 09:32:44 +1000
> BTW, you should rediff against Dave's current tree which has a few
> extra bits there.
I just rebased that, so feel free to use it as the base for
the patch now.
-
To unsubscribe from this list: send the line "unsubscrib
On Thu, 2006-29-06 at 16:47 -0700, David Miller wrote:
> From: Thomas Graf <[EMAIL PROTECTED]>
> Date: Fri, 30 Jun 2006 01:39:33 +0200
>
> > * jamal <[EMAIL PROTECTED]> 2006-06-29 19:23
> > > I know your intent is noble in trying to save the 32 bits on 64 bit
> > > machines (at least thats where y
"Bryan O'Sullivan" <[EMAIL PROTECTED]> wrote:
>
> diff -r fd5e733f02ac -r 9d943b828776
> drivers/infiniband/hw/ipath/ipath_file_ops.c
> --- a/drivers/infiniband/hw/ipath/ipath_file_ops.cThu Jun 29 14:33:25
> 2006 -0700
> +++ b/drivers/infiniband/hw/ipath/ipath_file_ops.cThu Jun 29 14:33:2
On Fri, 2006-30-06 at 01:39 +0200, Thomas Graf wrote:
> * jamal <[EMAIL PROTECTED]> 2006-06-29 19:23
> > not at all. Let me explain the design intent further below.
>
> Then let me show you what your code does:
>
> [mirred attached to filter on eth0 redirecting to ifb0]
>
> tcf_mirred():sk
From: Samuel Ortiz <[EMAIL PROTECTED]>
Date: Fri, 30 Jun 2006 09:56:07 +0300
> AU1000 FIR is broken, it should depend on SOC_AU1000.
>
> Spotted by Jean-Luc Leger.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
Applied, thanks.
-
To unsubscr
"Bryan O'Sullivan" <[EMAIL PROTECTED]> wrote:
>
> The mb() prevents the compiler from reordering on this function, with some
> versions
> of gcc and -Os optimization. The result is random failures in the EEPROM
> read
> without this change.
>
>
> Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
From: Samuel Ortiz <[EMAIL PROTECTED]>
Date: Fri, 30 Jun 2006 09:55:34 +0300
> irlan_client_discovery_indication calls rcu_read_lock and rcu_read_unlock, but
> returns without unlocking in an error case. Fix that by replacing the return
> with a goto so that the rcu_read_unlock always gets execut
This is intended to be an architecture specific function
so if the CPU does support HW dma to the CPU's L2 cache, the
architecture specific version of memcpy_nc() would not replace
the default definition which maps memcpy_nc() to memcpy().
For CPUs like the vast majority currently available, there
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Fri, 30 Jun 2006 01:39:33 +0200
> * jamal <[EMAIL PROTECTED]> 2006-06-29 19:23
> > I know your intent is noble in trying to save the 32 bits on 64 bit
> > machines (at least thats where your patch seems to have started) but the
> > cost:benefit ratio as
Hi Dave,
AU1000 FIR is broken, it should depend on SOC_AU1000.
Spotted by Jean-Luc Leger.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
drivers/net/irda/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers
Hi Dave,
irlan_client_discovery_indication calls rcu_read_lock and rcu_read_unlock, but
returns without unlocking in an error case. Fix that by replacing the return
with a goto so that the rcu_read_unlock always gets executed.
Signed-off-by: Josh Triplett <[EMAIL PROTECTED]>
Acked-by: Paul E. Mc
From: Bryan O'Sullivan <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 16:34:23 -0700
> I'm not quite following you, though I assume you're referring to Niagara
> or Rock :-) Are you saying a memcpy_nc would do worse than plain
> memcpy, or worse than some other memcpy-like routine?
It would do worse
On Fri, Jun 30, 2006 at 12:24:38AM +0200, Francois Romieu wrote:
> Nit below.
>
> Don Fry <[EMAIL PROTECTED]> :
> [...]
> > --- linux-2.6.17-git13/drivers/net/purge.pcnet32.c Thu Jun 29 13:28:24 2006
> > +++ linux-2.6.17-git13/drivers/net/pcnet32.cThu Jun 29 13:28:31 2006
> [...]
> > +#if
* jamal <[EMAIL PROTECTED]> 2006-06-29 19:23
> > What's currently
> > done in ifb:
> >
> > skb->dev = skb->input_dev;
> > skb->input_dev = dev;
> >
> > Confusing, isn't it?
>
> not at all. Let me explain the design intent further below.
Then let me show you what your code does:
[mirr
Ananda Raju <[EMAIL PROTECTED]> wrote:
>This patch enables TSO over IPv6. Currently Linux network stacks
>restricts TSO over IPv6 by clearing of the NETIF_F_TSO bit from
>"dev->features". This patch will remove this restriction.
Thanks, looks good over all.
>SKB_G
On Thu, 2006-06-29 at 15:03 -0700, David Miller wrote:
> I'm not good with names :-)
Heh. I'll call it memcpy_nc for now, then, and people can retch all
over the name as they please when I submit a more suitably generic
patch.
> Note that there also might be cases where using such a memcpy
> va
I noticed the other email carrying a patch. Let me respond to this email
and hopefully that will address the patch.
On Thu, 2006-29-06 at 10:51 +0200, Thomas Graf wrote:
> * jamal <[EMAIL PROTECTED]> 2006-06-28 09:46
[..]
> I disagree, iflink information is bogus once we start redirecting.
Aft
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i'm too hunting use-after-free bugs - the ones fixed below fix certain
> crashes, but i'm still seeing a nasty one.
>
> the crash is independent on lockdep enabled or disabled. See:
>
> http://redhat.com/~mingo/misc/
>
> for the config and the cras
On Thu, 2006-29-06 at 18:13 -0400, Shailabh Nagar wrote:
>
> And now I remember why I didn't go down that path earlier. Relayfs is one-way
> kernel->user and lacks the ability to send query commands from user space
> that we need. Either we would need to send commands up through a separate
> int
On Thu, 2006-29-06 at 16:01 -0400, Shailabh Nagar wrote:
>
> Jamal,
> any thoughts on the flow control capabilities of netlink that apply here
> ? Usage of the connection is to supply statistics data to userspace.
>
if you want reliable delivery, then you cant just depend on async events
from
From: Ananda Raju <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 18:18:10 -0400 (EDT)
> This patch enables TSO over IPv6. Currently Linux network stacks
> restricts TSO over IPv6 by clearing of the NETIF_F_TSO bit from
> "dev->features". This patch will remove this restriction.
Gene
Nit below.
Don Fry <[EMAIL PROTECTED]> :
[...]
> --- linux-2.6.17-git13/drivers/net/purge.pcnet32.cThu Jun 29 13:28:24 2006
> +++ linux-2.6.17-git13/drivers/net/pcnet32.c Thu Jun 29 13:28:31 2006
[...]
> +#ifdef CONFIG_PCNET32_NAPI
> +static int pcnet32_poll(struct net_device *dev, int *budge
On Thu, Jun 29, 2006 at 10:50:00AM -0400, Bill Davidsen wrote:
> >Basically the mostlikely end-result is I don't know what there is a
> >problem and my customer doesn't know that there is a problem but they're
> >just not getting as many hits to their site that they otherwise would.
> >
> >Ofcourse
Hi,
This patch enables TSO over IPv6. Currently Linux network stacks
restricts TSO over IPv6 by clearing of the NETIF_F_TSO bit from
"dev->features". This patch will remove this restriction.
This patch will introduce a new flag NETIF_F_TSO6 which will be used
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r e43b4df874a9 -r 125471ee6c68 drivers/infiniband/hw/ipath/ipath_driver.c
--- a/drivers/infiniband/hw/ipath/ipath_driver.cThu Jun 29 14:33:25
2006 -0700
+++ b/drivers/infiniband/hw/ipat
Signed-off-by: Robert Walsh <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 081142011371 -r ac81d2563bba drivers/infiniband/hw/ipath/ipath_mr.c
--- a/drivers/infiniband/hw/ipath/ipath_mr.cThu Jun 29 14:33:25 2006 -0700
+++ b/drivers/infiniband/hw/ipath/ipath_mr.
We must increment uaddr by size we are reading or writing, since it's
passed as a char *, not a pointer to the appropriate size.
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 8fbb5d71823a -r a7c1ad1e090b drivers/infiniband/hw/ipath/ipath
From: Bryan O'Sullivan <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 14:41:30 -0700
> +/*
> + * Copy data. Try not to pollute the dcache with the source data,
> + * because we won't be reading it again.
> + */
> +#if defined(CONFIG_X86_64)
> +void *ipath_memcpy_nc(void *dest, const void *src, size_t
Sam Vilain wrote:
> jamal wrote:
>>> note: personally I'm absolutely not against virtualizing
>>> the device names so that each guest can have a separate
>>> name space for devices, but there should be a way to
>>> 'see' _and_ 'identify' the interfaces from outside
>>> (i.e. host or spectator conte
Signed-off-by: Robert Walsh <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 8f08597cacd2 -r 081142011371 drivers/infiniband/hw/ipath/ipath_qp.c
--- a/drivers/infiniband/hw/ipath/ipath_qp.cThu Jun 29 14:33:25 2006 -0700
+++ b/drivers/infiniband/hw/ipath/ipath_qp.
From: Bryan O'Sullivan <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 15:01:39 -0700
> The support for write combining in the kernel is not in a state where
> that makes any sense at the moment.
Please fix the generic code if it doesn't provide the facility
you need at the moment. Don't shoe horn it
Do an extra check to see if in-memory tail changed while processing
packets, and if so, going back through the loop again (but only once
per call to ipath_kreceive()). In practice, this seems to be enough
to guarantee that if we crossed the clearing of an interrupt at start of
ipath_intr with a s
On 29/06/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
[snip]
OK. Perhaps try setting 8k stacks?
Disable lockdep?
I don't see that now. I will try to reproduce this with a previous
config + Ingo's "Ignore loglevel on printks" patch.
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Tes
Ordering of writethrough store buffers needs to be forced, and we need
to use ifdef to get writethrough behavior to InfiniPath buffers, because
there is no generic way to specify that at this time (similar to code
in char/drm/drm_vm.c and block/z2ram.c).
Signed-off-by: John Gregor <[EMAIL PROTECTE
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 28e3d8204fdb -r addf90abc724 drivers/infiniband/hw/ipath/ipath_mad.c
--- a/drivers/infiniband/hw/ipath/ipath_mad.c Fri Jun 23 22:47:27 2006 +0700
+++ b/drivers/infiniband/hw/ipath/ipath_
From: Bryan O'Sullivan <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 14:41:29 -0700
> ipath_core-$(CONFIG_X86_64) += ipath_wc_x86_64.o
> +ipath_core-$(CONFIG_PPC64) += ipath_wc_ppc64.o
Again, don't put these kinds of cpu specific functions
into the infiniband driver. They are potentially globally
We can't tell for sure if any packets are in the infinipath receive buffer
when we shut down a chip port. Normally this is taken care of by orderly
shutdown, but when processes are terminated, or sending process has a bug,
we can continue to receive packets. So rather than writing zero to the
a
These limits are somewhat artificial in that we don't actually have any
device limits. However, the verbs layer expects that such limits exist
and are enforced, so we make up arbitrary (but sensible) limits.
Signed-off-by: Robert Walsh <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL P
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r a94e9f9c9c23 -r e43b4df874a9 drivers/infiniband/hw/ipath/ipath_driver.c
--- a/drivers/infiniband/hw/ipath/ipath_driver.cThu Jun 29 14:33:25
2006 -0700
+++ b/drivers/infiniband/hw/ipat
The two arrays only had space for 4 units.
Also changed from ipath_set_sps_lid() to ipath_set_lid(); the sps
was leftover.
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 1bef8244297a -r 3ceb73f8bde0 drivers/infiniband/hw/ipath/ipath_comm
The receive work queue size should be ignored if the QP is created
to use a shared receive queue according to the IB spec.
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 9b423c45af8b -r 31c382d8210a drivers/infiniband/hw/ipath/ipath_q
This is not a DMA target, so no need to use dma_alloc_coherent on it.
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 9d943b828776 -r 9c072f8e7e68 drivers/infiniband/hw/ipath/ipath_driver.c
--- a/drivers/infiniband/hw/ipath/ipath_driver.cThu Jun 29 14:33:25
2006 -0700
+++ b/d
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 811021b6c112 -r 8e39364c2402 drivers/infiniband/hw/ipath/ipath_ud.c
--- a/drivers/infiniband/hw/ipath/ipath_ud.cThu Jun 29 14:33:26 2006 -0700
+++ b/drivers/infiniband/hw/ipath/ipath_u
Signed-off-by: Robert Walsh <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 600ceb6aeb8c -r 8f08597cacd2 drivers/infiniband/hw/ipath/ipath_kernel.h
--- a/drivers/infiniband/hw/ipath/ipath_kernel.hThu Jun 29 14:33:25
2006 -0700
+++ b/drivers/infiniband/hw/ip
Signed-off-by: Robert Walsh <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 1e1f3da0e78d -r 21d5d64750ac drivers/infiniband/hw/ipath/ipath_layer.c
--- a/drivers/infiniband/hw/ipath/ipath_layer.c Thu Jun 29 14:33:25 2006 -0700
+++ b/drivers/infiniband/hw/ipath/ipath_
The tail register read became redundant as the result of earlier receive
interrupt bug fixes.
Drop another unneeded register read.
And another line that got duplicated.
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r e952aedb0e94 -r 4c58
1 - 100 of 226 matches
Mail list logo
