From: Roland Dreier <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 22:23:01 -0700
> Also, looking at the complexity and bug-fixing effort that go into
> making TSO work vs the really pretty small gain it gives also makes
> part of me wonder whether the noble proclamations about
> maintainability are a
On Fri, Aug 17, 2007 at 05:03:41PM -0700, Stephen Hemminger wrote:
> On Fri, 17 Aug 2007 05:42:13 -0700 (PDT)
> Kevin E <[EMAIL PROTECTED]> wrote:
>
> > Hi all,
> >
> > I've read where the onboard Marvell lan controller on
> > some Gigabyte boards don't work. I've got two systems
> > using t
> This is also a series of falsehoods. All packet filtering,
> queue management, and packet scheduling facilities work perfectly
> fine and as designed with both LRO and TSO.
I'm not sure I follow. Perhaps "broken" was too strong a word to use,
but if you pass a huge segment to a NIC with TSO
The documentation simply doesn't say "+m" is allowed. The code to
allow it was added for the benefit of people who do not read the
documentation. Documentation for "+m" might get added later if it
is decided this [the code, not the documentation] is a sane thing
to have (which isn't directly obv
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 20:31:39 -0700
> On Fri, 17 Aug 2007 18:57:00 -0700
> Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> >
> > On Fri, 2007-08-17 at 18:54 -0700, Stephen Hemminger wrote:
> > > On Fri, 17 Aug 2007 18:49:34 -0700
> > > Arjan van de V
On Sat, 18 Aug 2007, Satyam Sharma wrote:
>
> No code does (or would do, or should do):
>
> x.counter++;
>
> on an "atomic_t x;" anyway.
That's just an example of a general problem.
No, you don't use "x.counter++". But you *do* use
if (atomic_read(&x) <= 1)
and loading into a
On Fri, 17 Aug 2007 18:57:00 -0700
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-08-17 at 18:54 -0700, Stephen Hemminger wrote:
> > On Fri, 17 Aug 2007 18:49:34 -0700
> > Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemmin
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > > > The "asm volatile" implementation does have exactly the same
> > > > > reordering guarantees as the "volatile cast" thing,
> > > >
> > > > I don't think so.
> > >
> > > "asm volatile" creates a side effect.
> >
> > Yeah.
> >
> > > Side
The "asm volatile" implementation does have exactly the same
reordering guarantees as the "volatile cast" thing,
I don't think so.
"asm volatile" creates a side effect.
Yeah.
Side effects aren't
allowed to be reordered wrt sequence points.
Yeah.
This is exactly
the same reason as why "
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
>
> > I didn't quite understand what you said here, so I'll tell what I think:
> >
> > * foo() is a compiler barrier if the definition of foo() is invisible to
> > the compiler at a callsite.
> >
> > * foo() is also a compiler ba
On Fri, 2007-08-17 at 18:54 -0700, Stephen Hemminger wrote:
> On Fri, 17 Aug 2007 18:49:34 -0700
> Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> >
> > On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemminger wrote:
> > > Tne network code does memset for 6 and 8 byte values, that can easily
> > > b
On Fri, 17 Aug 2007 18:49:34 -0700
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemminger wrote:
> > Tne network code does memset for 6 and 8 byte values, that can easily
> > be optimized into simple assignments without string instructions.
>
>
> so
On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemminger wrote:
> Tne network code does memset for 6 and 8 byte values, that can easily
> be optimized into simple assignments without string instructions.
so... question.
Why are we doing this by hand? Wouldn't gcc just generate this code in
the first
Run the 802 related protocols through Lindent (and hand cleanup)
to fix indentation and whitespace style issues.
--- a/net/802/fc.c 2007-08-17 14:39:56.0 -0400
+++ b/net/802/fc.c 2007-08-17 14:50:52.0 -0400
@@ -44,33 +44,29 @@ static int fc_header(struct sk_buff *skb
David Miller wrote:
From: "Kok, Auke" <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 18:21:25 -0700
this sounds highly optimistic ("64 queues is enough for everyone"?)
and probably will be quickly outdated by both hardware and demand...
As such drivers appear in the tree we can adjust the value.
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > > > atomic_dec() writes
> > > > > to memory, so it _does_ have "volatile semantics", implicitly, as
> > > > > long as the compiler cannot optimise the atomic variable away
> > > > > completely -- any store counts as a side effect.
> > > >
> >
Get rid of using DPRINTK macro in ATM and use pr_debug (in kernel.h).
Using the standard macro is cleaner and forces code to check for bad arguments
and formatting.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/net/atm/clip.c2007-08-17 15:05:49.0 -0400
+++ b/net/atm/clip.
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 18:28:07 -0700
> Plan C was replacing MULTIQUEUE boolean with a int value 1 ... 256.
> All this was a one day "what if" exercise, not really a big churn..
Yes, that's another reasonable approach.
-
To unsubscribe from this list: s
From: "Kok, Auke" <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 18:21:25 -0700
> this sounds highly optimistic ("64 queues is enough for everyone"?)
> and probably will be quickly outdated by both hardware and demand...
As such drivers appear in the tree we can adjust the value.
Even the most aggre
On Fri, 17 Aug 2007, Christoph Lameter wrote:
> On Fri, 17 Aug 2007, Paul E. McKenney wrote:
>
> > On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
> > > On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
> > > >
> > > > gcc bugzilla bug #33102, for whatever that ends
On Fri, 17 Aug 2007 18:21:25 -0700
"Kok, Auke" <[EMAIL PROTECTED]> wrote:
> David Miller wrote:
> > From: Stephen Hemminger <[EMAIL PROTECTED]>
> > Date: Fri, 17 Aug 2007 17:49:09 -0700
> >
> >> Fix optimization of netdev_priv() lost by the addition of multiqueue.
> >>
> >> Only configurations th
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
> On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
> > On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
> > >
> > > gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)
> >
> > I had totally forgotten that I'
David Miller wrote:
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 17:49:09 -0700
Fix optimization of netdev_priv() lost by the addition of multiqueue.
Only configurations that define MULITQUEUE need the extra overhead in
netdevice structure and the loss of the netdev_priv
Rick Jones wrote:
Hi Rick, allow me to respond on my way out on a Friday... :-)
> hpcpc109:~/netperf2_trunk# src/netperf -t TCP_RR -H 192.168.2.105 -D
> 1.0 -l 15 TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0
> AF_INET to 192.168.2.105 (192.168.2.105) port 0 AF_INET : demo :
> first burs
On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
> On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
> >
> > gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)
>
> I had totally forgotten that I'd already filed that bug more
> than six years ago until t
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 17:49:09 -0700
> Fix optimization of netdev_priv() lost by the addition of multiqueue.
>
> Only configurations that define MULITQUEUE need the extra overhead in
> netdevice structure and the loss of the netdev_priv optimization.
>
Brandon Philips wrote:
> Conversion of e1000e probe() and remove() to devres.
>
> Depends on "[patch 1/4] Update net core to use devres."
>
> Signed-off-by: Brandon Philips <[EMAIL PROTECTED]>
Acked-by: Tejun Heo <[EMAIL PROTECTED]>
--
tejun
-
To unsubscribe from this list: send the line "unsu
Fix optimization of netdev_priv() lost by the addition of multiqueue.
Only configurations that define MULITQUEUE need the extra overhead in
netdevice structure and the loss of the netdev_priv optimization.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/include/linux/netdevice.h 2007
No it does not have any volatile semantics. atomic_dec() can be
reordered
at will by the compiler within the current basic unit if you do not
add a
barrier.
"volatile" has nothing to do with reordering.
If you're talking of "volatile" the type-qualifier keyword, then
http://lkml.org/lkml/200
On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
>
> gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)
I had totally forgotten that I'd already filed that bug more
than six years ago until they just closed yours as a duplicate
of mine :)
Good luck in getting it
atomic_dec() writes
to memory, so it _does_ have "volatile semantics", implicitly, as
long as the compiler cannot optimise the atomic variable away
completely -- any store counts as a side effect.
I don't think an atomic_dec() implemented as an inline "asm volatile"
or one that uses a "forget" m
On Fri, 17 Aug 2007 05:42:13 -0700 (PDT)
Kevin E <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've read where the onboard Marvell lan controller on
> some Gigabyte boards don't work. I've got two systems
> using the same Gigabyte board, on one the LAN works on
> the other it dies like describe
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 16:31:07 -0700
> > > > When using RDMA you lose the capability to do packet shaping,
> > > > classification, and all the other wonderful networking facilities
> > > > you've grown to love and use over the years.
> > >
> > > Sa
On Thu, Aug 16, 2007 at 08:50:30PM -0700, Linus Torvalds wrote:
> Just try it yourself:
>
> volatile int i;
> int j;
>
> int testme(void)
> {
> return i <= 1;
> }
>
> int testme2(void)
> {
> return j <= 1;
> }
>
> and c
#define forget(a) __asm__ __volatile__ ("" :"=m" (a) :"m" (a))
[ This is exactly equivalent to using "+m" in the constraints, as
recently
explained on a GCC list somewhere, in response to the patch in my
bitops
series a few weeks back where I thought "+m" was bogus. ]
[It wasn't ex
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 16:19:28 -0700
> The subqueue is only referenced in start/stop queue and that only happens
> once per packet on normal tx, and only if multiqueue is used.
If it only happens when multiqueue, then why does loopback need
at least on
Tne network code does memset for 6 and 8 byte values, that can easily
be optimized into simple assignments without string instructions.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/include/asm-i386/string.h 2007-08-17 15:14:37.0 -0700
+++ b/include/asm-i386/string.h 2007-08
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > > No it does not have any volatile semantics. atomic_dec() can be
> > > > reordered
> > > > at will by the compiler within the current basic unit if you do not add
> > > > a
> > > > barrier.
> > >
> > > "volatile" has nothing to do with reord
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > #define forget(a) __asm__ __volatile__ ("" :"=m" (a) :"m" (a))
> >
> > [ This is exactly equivalent to using "+m" in the constraints, as recently
> > explained on a GCC list somewhere, in response to the patch in my bitops
> > series a fe
> > > When using RDMA you lose the capability to do packet shaping,
> > > classification, and all the other wonderful networking facilities
> > > you've grown to love and use over the years.
> >
> > Same thing with TSO and LRO and who knows what else.
>
> Not true at all. Full classifi
The ethernet header management only needs to handle a fixed
size address (6 bytes). If the memcpy/memset are changed to
be passed a constant length, then compiler can optimize for
this case (and if it is smart eliminate string instructions).
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--
On Fri, 17 Aug 2007 16:04:09 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Fri, 17 Aug 2007 15:40:22 -0700
>
> > Compile tested only!!!
>
> Obviously. The first loopback transmit is guarenteed to crash.
That is fixable.
> > Fix optim
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 15:40:22 -0700
> Compile tested only!!!
Obviously. The first loopback transmit is guarenteed to crash.
> Fix optimization of netdev_priv() lost by the addition of multiqueue.
> Move the variable size subqueues to after the cons
#define forget(a) __asm__ __volatile__ ("" :"=m" (a) :"m" (a))
[ This is exactly equivalent to using "+m" in the constraints, as
recently
explained on a GCC list somewhere, in response to the patch in my
bitops
series a few weeks back where I thought "+m" was bogus. ]
[It wasn't ex
Here, I should obviously admit that the semantics of *(volatile int
*)&
aren't any neater or well-defined in the _language standard_ at all.
The
standard does say (verbatim) "precisely what constitutes as access to
object of volatile-qualified type is implementation-defined", but GCC
does help u
Compile tested only!!!
Fix optimization of netdev_priv() lost by the addition of multiqueue.
Move the variable size subqueues to after the constant size priv area.
When putting back the old netdev_priv() code, I tried to make it
clearer by using roundup() and ALIGN() macros.
--- a/include/linux
Now the second wording *IS* technically correct, but come on, it's
24 words long whereas the original one was 3 -- and hopefully anybody
reading the shorter phrase *would* have known anyway what was meant,
without having to be pedantic about it :-)
Well you were talking pretty formal (and detail
In a reasonable world, gcc should just make that be (on x86)
addl $1,i(%rip)
on x86-64, which is indeed what it does without the volatile. But with
the
volatile, the compiler gets really nervous, and doesn't dare do it in
one
instruction, and thus generates crap like
movl
(and yes, it is perfectly legitimate to
want a non-volatile read for a data type that you also want to do
atomic RMW operations on)
...which is undefined behaviour in C (and GCC) when that data is
declared volatile, which is a good argument against implementing
atomics that way in itself.
Segh
Of course, since *normal* accesses aren't necessarily limited wrt
re-ordering, the question then becomes one of "with regard to *what*
does
it limit re-ordering?".
A C compiler that re-orders two different volatile accesses that have a
sequence point in between them is pretty clearly a buggy co
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 12:52:39 -0700
> > When using RDMA you lose the capability to do packet shaping,
> > classification, and all the other wonderful networking facilities
> > you've grown to love and use over the years.
>
> Same thing with TSO and LRO
Conversion of e1000e probe() and remove() to devres.
Depends on "[patch 1/4] Update net core to use devres."
Signed-off-by: Brandon Philips <[EMAIL PROTECTED]>
---
drivers/net/e1000e/netdev.c | 70 ++--
1 file changed, 17 insertions(+), 53 deletions(-)
On Fri, Aug 17, 2007 at 12:49:00PM -0700, Arjan van de Ven wrote:
>
> On Fri, 2007-08-17 at 12:49 -0700, Paul E. McKenney wrote:
> > > > What about reading values modified in interrupt handlers, as in your
> > > > "random" case? Or is this a bug where the user of atomic_read() is
> > > > invali
On Fri, 2007-08-17 at 12:49 -0700, Paul E. McKenney wrote:
> > > What about reading values modified in interrupt handlers, as in your
> > > "random" case? Or is this a bug where the user of atomic_read() is
> > > invalidly expecting a read each time it is called?
> >
> > the interrupt handler
> > Isn't RDMA _part_ of the "software net stack" within Linux?
> It very much is not so.
This is just nit-picking. You can draw the boundary of the "software
net stack" wherever you want, but I think Sean's point was just that
RDMA drivers already are part of Linux, and we all want them to ge
On Fri, Aug 17, 2007 at 11:54:33AM -0700, Arjan van de Ven wrote:
>
> On Fri, 2007-08-17 at 12:50 -0600, Chris Friesen wrote:
> > Linus Torvalds wrote:
> >
> > > - in other words, the *only* possible meaning for "volatile" is a purely
> > >single-CPU meaning. And if you only have a single C
On Fri, 17 Aug 2007, Chris Friesen wrote:
>
> I assume you mean "except for IO-related code and 'random' values like
> jiffies" as you mention later on?
Yes. There *are* valid uses for "volatile", but they have remained the
same for the last few years:
- "jiffies"
- internal per-architecture
On Fri, 2007-08-17 at 12:50 -0600, Chris Friesen wrote:
> Linus Torvalds wrote:
>
> > - in other words, the *only* possible meaning for "volatile" is a purely
> >single-CPU meaning. And if you only have a single CPU involved in the
> >process, the "volatile" is by definition pointless
On Sat, Aug 18, 2007 at 12:01:38AM +0530, Satyam Sharma wrote:
>
>
> On Fri, 17 Aug 2007, Paul E. McKenney wrote:
>
> > On Fri, Aug 17, 2007 at 01:09:08PM +0530, Satyam Sharma wrote:
> > >
> > > On Thu, 16 Aug 2007, Paul E. McKenney wrote:
> > >
> > > > On Fri, Aug 17, 2007 at 07:59:02AM +0800
On Fri, Aug 17, 2007 at 08:53:57AM -0700, Paul E. McKenney wrote:
> On Fri, Aug 17, 2007 at 09:56:45AM +0200, Peter Zijlstra wrote:
> > On Thu, 2007-08-16 at 09:01 -0700, Paul E. McKenney wrote:
> > > On Thu, Aug 16, 2007 at 04:25:07PM +0200, Peter Zijlstra wrote:
> > > >
> > > > There seem to be
Linus Torvalds wrote:
- in other words, the *only* possible meaning for "volatile" is a purely
single-CPU meaning. And if you only have a single CPU involved in the
process, the "volatile" is by definition pointless (because even
without a volatile, the compiler is required to make t
Paul E. McKenney wrote:
On Fri, Aug 17, 2007 at 09:56:45AM +0200, Peter Zijlstra wrote:
On Thu, 2007-08-16 at 09:01 -0700, Paul E. McKenney wrote:
On Thu, Aug 16, 2007 at 04:25:07PM +0200, Peter Zijlstra wrote:
There seem to be some unbalanced rcu_read_{,un}lock() issues of late
On Fri, 17 Aug 2007, Segher Boessenkool wrote:
> > > atomic_dec() already has volatile behavior everywhere, so this is
> > > semantically
> > > okay, but this code (and any like it) should be calling cpu_relax() each
> > > iteration through the loop, unless there's a compelling reason not to.
>
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
> On Fri, Aug 17, 2007 at 01:09:08PM +0530, Satyam Sharma wrote:
> >
> > On Thu, 16 Aug 2007, Paul E. McKenney wrote:
> >
> > > On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote:
> > > >
> > > > First of all, I think this illustrates that
The existing OF glue code was crufty and broken. Rather than fix it, it
will be removed, and the ethernet driver now talks to the device tree
directly.
The old, non-CONFIG_PPC_CPM_NEW_BINDING code can go away once CPM
platforms are dropped from arch/ppc (which will hopefully be soon), and
existin
The following patchset includes several updates for the fs_enet driver,
the most prominent being conversion to an of_platform device (with
platform_device code remaining until arch/ppc goes away). It also
includes a generic MDIO bitbang library, and converts fs_enet to use it.
I have a powerpc pa
Previously, bitbanged MDIO was only supported in individual
hardware-specific drivers. This code factors out the higher level
protocol implementation, reducing the hardware-specific portion to
functions setting direction, data, and clock.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
drivers
The existing OF glue code was crufty and broken. Rather than fix it, it
will be removed, and the ethernet driver now talks to the device tree
directly.
The old, non-CONFIG_PPC_CPM_NEW_BINDING code can go away once CPM
platforms are dropped from arch/ppc (which will hopefully be soon), and
existin
Mostly a bunch of __iomem annotations.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/fs_enet-main.c | 16 +-
drivers/net/fs_enet/fs_enet.h | 30 +-
drivers/net/fs_enet/mac-fcc.c | 60 ---
drivers/net/f
At least some hardware driven by this driver needs receive buffers
to be aligned on a 16-byte boundary. This usually happens by chance,
but it breaks if slab debugging is enabled.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/fs_enet-main.c | 21 +++--
d
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/fs_enet-main.c | 85 ---
drivers/net/fs_enet/fs_enet.h |4 +-
drivers/net/fs_enet/mac-fcc.c |1 -
drivers/net/fs_enet/mii-fec.c |1 -
4 files changed, 41 insertions(+)
These macros accomplish nothing other than defeating type checking.
This patch also fixes one instance of the wrong register size being
used that was revealed by enabling type checking.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/mac-fcc.c | 25 ---
This driver can't handle an interrupt immediately after request_irq
(making it fail with CONFIG_DEBUG_SHIRQ), and has unshared interrupts
on all hardware I'm aware of.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/fs_enet-main.c |2 +-
1 files changed, 1 insertions(+),
atomic_dec() already has volatile behavior everywhere, so this is
semantically
okay, but this code (and any like it) should be calling cpu_relax()
each
iteration through the loop, unless there's a compelling reason not
to. I'll
allow that for some hardware drivers (possibly this one) such a
co
Part of the motivation here is to fix heisenbugs. If I knew
where they
By the same token we should probably disable optimisations
altogether since that too can create heisenbugs.
Almost everything is a tradeoff; and so is this. I don't
believe most people would find disabling all compiler
op
On Fri, 17 Aug 2007, Nick Piggin wrote:
>
> That's not obviously just taste to me. Not when the primitive has many
> (perhaps, the majority) of uses that do not require said barriers. And
> this is not solely about the code generation (which, as Paul says, is
> relatively minor even on x86). I p
On Fri, Aug 17, 2007 at 09:56:45AM +0200, Peter Zijlstra wrote:
> On Thu, 2007-08-16 at 09:01 -0700, Paul E. McKenney wrote:
> > On Thu, Aug 16, 2007 at 04:25:07PM +0200, Peter Zijlstra wrote:
> > >
> > > There seem to be some unbalanced rcu_read_{,un}lock() issues of late,
> > > how about doing s
On Fri, Aug 17, 2007 at 01:09:08PM +0530, Satyam Sharma wrote:
>
>
> On Thu, 16 Aug 2007, Paul E. McKenney wrote:
>
> > On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote:
> > > On Thu, Aug 16, 2007 at 09:34:41AM -0700, Paul E. McKenney wrote:
> > > >
> > > > The compiler can also reorde
Removes the use of bitfields from the ibmveth driver. This results
in slightly smaller object code.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 90
linux-2.6-bjking1/drivers/net/ibmveth.h | 56 -
Add ethtool hooks to ibmveth to retrieve driver statistics.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 51
1 file changed, 51 insertions(+)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_driver_stats
drivers/
Removes dead frag processing code from ibmveth. Since NETIF_F_SG was
not set, this code was never executed. Also, since the ibmveth
interface can only handle 6 fragments, core networking code would need
to be modified in order to efficiently enable this support.
Signed-off-by: Brian King <[EMAIL
Add handlers for get_tso and get_ufo to prevent errors being printed
by ethtool.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c |2 ++
1 file changed, 2 insertions(+)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_get_tso drivers/net/ibmveth.c
--
This patch adds the appropriate ethtool hooks to allow for enabling/disabling
of hypervisor assisted checksum offload for TCP.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 125 +++-
linux-2.6-bjking1/drivers/net/ibmveth
This patchset enables TCP checksum offload support for IPV4
on ibmveth. This completely eliminates the generation and checking of
the checksum for packets that are completely virtual and never
touch a physical network. A simple TCP_STREAM netperf run on
a virtual network with maximum mtu set yield
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
>
> > On Fri, 17 Aug 2007, Nick Piggin wrote:
> >
> > > Because they should be thinking about them in terms of barriers, over
> > > which the compiler / CPU is not to reorder accesses or cache memory
> > > operations, rather than "
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
Satyam Sharma wrote:
It is very obvious. msleep calls schedule() (ie. sleeps), which is
always a barrier.
Probably you didn't mean that, but no, schedule() is not
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> [...]
> > You think both these are equivalent in terms of "looks":
> >
> > |
> > while (!atomic_read(&v)) { | while (!atomic_read_xxx(&v)) {
> > ...
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > On Fri, 17 Aug 2007, Nick Piggin wrote:
> > > Satyam Sharma wrote:
> > >
> > > It is very obvious. msleep calls schedule() (ie. sleeps), which is
> > > always a barrier.
> >
> > Probably you didn't mean that, but no, schedule()
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
Because they should be thinking about them in terms of barriers, over
which the compiler / CPU is not to reorder accesses or cache memory
operations, rather than "special" "volatile" accesses.
This is obviously just a taste thin
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
I think they would both be equally ugly,
You think both these are equivalent in terms of "looks":
|
while (!atomic_read(&v)) { | while (!atomic_read_xxx(&v)) {
...
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
Satyam Sharma wrote:
It is very obvious. msleep calls schedule() (ie. sleeps), which is
always a barrier.
Probably you didn't mean that, but no, schedule() is not barrier because
it sleeps. It's a barrier because it's invisible
Nick Piggin wrote:
> Satyam Sharma wrote:
>> And we have driver / subsystem maintainers such as Stefan
>> coming up and admitting that often a lot of code that's written to use
>> atomic_read() does assume the read will not be elided by the compiler.
>
> So these are broken on i386 and x86-64?
Th
I wrote:
> Nick Piggin wrote:
>> You might find that these places that appear to need barriers are
>> buggy for other reasons anyway. Can you point to some in-tree code
>> we can have a look at?
>
> I could, or could not, if I were through with auditing the code. I
> remembered one case and poste
Nick Piggin wrote:
> Stefan Richter wrote:
>> For architecture port authors, there is Documentation/atomic_ops.txt.
>> Driver authors also can learn something from that document, as it
>> indirectly documents the atomic_t and bitops APIs.
>
> "Semantics and Behavior of Atomic and Bitmask Operation
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > [...]
> > The point is about *author expecations*. If people do expect atomic_read()
> > (or a variant thereof) to have volatile semantics, why not give them such
> > a variant?
>
> Because they should be thinking about them in
On Fri, 17 Aug 2007, Paul Mackerras wrote:
> Satyam Sharma writes:
>
> > I wonder if this'll generate smaller and better code than _both_ the
> > other atomic_read_volatile() variants. Would need to build allyesconfig
> > on lots of diff arch's etc to test the theory though.
>
> I'm sure it wo
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> >
> > On Fri, 17 Aug 2007, Nick Piggin wrote:
>
> > > Also, why would you want to make these insane accessors for atomic_t
> > > types? Just make sure everybody knows the basics of barriers, and they
> > > can apply that knowledg
On Fri, 17 Aug 2007, Andi Kleen wrote:
> On Friday 17 August 2007 05:42, Linus Torvalds wrote:
> > On Fri, 17 Aug 2007, Paul Mackerras wrote:
> > > I'm really surprised it's as much as a few K. I tried it on powerpc
> > > and it only saved 40 bytes (10 instructions) for a G5 config.
> >
> > One
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> >
> > On Fri, 17 Aug 2007, Nick Piggin wrote:
>
> > > > Sure, now
> > > > that I learned of these properties I can start to audit code and insert
> > > > barriers where I believe they are needed, but this simply means that
> > >
Satyam Sharma writes:
> I wonder if this'll generate smaller and better code than _both_ the
> other atomic_read_volatile() variants. Would need to build allyesconfig
> on lots of diff arch's etc to test the theory though.
I'm sure it would be a tiny effect.
This whole thread is arguing about ef
1 - 100 of 119 matches
Mail list logo
