* Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
From: Herbert Xu @ 2007-08-20 0:18 UTC (permalink / raw)
To: Felix Marti
Cc: davem, sean.hefty, netdev, rdreier, general, linux-kernel, jeff
In-Reply-To: <8A71B368A89016469F72CD08050AD334018E208F@maui.asicdesigners.com>
Felix Marti <felix@chelsio.com> wrote:
>
> [Felix Marti] Aren't you confusing memory and bus BW here? - RDMA
> enables DMA from/to application buffers removing the user-to-kernel/
> kernel-to-user memory copy with is a significant overhead at the
> rates we're talking about: memory copy at 20Gbps (10Gbps in and 10Gbps
> out) requires 60Gbps of BW on most common platforms. So, receiving and
> transmitting at 10Gbps with LRO and TSO requires 80Gbps of system
> memory BW (which is beyond what most systems can do) whereas RDMA can
> do with 20Gbps!
Actually this is false. TSO only requires a copy if the user
chooses to use the sendmsg interface instead of sendpage. The
same is true for RDMA really. Except that instead of having to
switch your application to sendfile/splice, you're switching it
to RDMA.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Please pull 'upstream-davem' branch of wireless-2.6
From: David Miller @ 2007-08-19 23:32 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070815003410.GJ7198-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Tue, 14 Aug 2007 20:34:10 -0400
> Johannes Berg (1):
> radiotap parser: accept all other fields
>
> Larry Finger (1):
> mac80211: Add SIOCGIWTXPOWER routine
I've rebased net-2.6.24 and added in these two wireless
patches, thanks!
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
From: Andi Kleen @ 2007-08-19 23:27 UTC (permalink / raw)
To: Felix Marti; +Cc: jeff, netdev, rdreier, linux-kernel, general, David Miller
In-Reply-To: <8A71B368A89016469F72CD08050AD334018E209C@maui.asicdesigners.com>
"Felix Marti" <felix@chelsio.com> writes:
> what benefits does the TSO infrastructure give the
> non-TSO capable devices?
It improves performance on software queueing devices between guests
and hypervisors. This is a more and more important application these
days. Even when the system running the Hypervisor has a non TSO
capable device in the end it'll still save CPU cycles this way. Right now
virtualized IO tends to much more CPU intensive than direct IO so any
help it can get is beneficial.
It also makes loopback faster, although given that's probably not that
useful.
And a lot of the "TSO infrastructure" was needed for zero copy TX anyways,
which benefits most reasonable modern NICs (anything with hardware
checksumming)
-Andi
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
From: David Miller @ 2007-08-19 23:12 UTC (permalink / raw)
To: andi; +Cc: jeff, netdev, rdreier, linux-kernel, general
In-Reply-To: <p73hcmv14wo.fsf@bingen.suse.de>
From: Andi Kleen <andi@firstfloor.org>
Date: 20 Aug 2007 01:27:35 +0200
> "Felix Marti" <felix@chelsio.com> writes:
>
> > what benefits does the TSO infrastructure give the
> > non-TSO capable devices?
>
> It improves performance on software queueing devices between guests
> and hypervisors. This is a more and more important application these
> days. Even when the system running the Hypervisor has a non TSO
> capable device in the end it'll still save CPU cycles this way. Right now
> virtualized IO tends to much more CPU intensive than direct IO so any
> help it can get is beneficial.
>
> It also makes loopback faster, although given that's probably not that
> useful.
>
> And a lot of the "TSO infrastructure" was needed for zero copy TX anyways,
> which benefits most reasonable modern NICs (anything with hardware
> checksumming)
And also, you can enable TSO generation for a non-TSO-hw device and
get all of the segmentation overhead reduction gains which works out
as a pure win as long as the device can at a minimum do checksumming.
^ permalink raw reply
* Re: Marvell 88E8056 gigabit ethernet controller
From: Eric Preston @ 2007-08-19 23:04 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linux-kernel, netdev
In-Reply-To: <20070819113400.12f5570c@localhost>
On 19-Aug-07, at 2:34 PM, Stephen Hemminger wrote:
> The driver prints some chip version info at startup, that might
> be helpful in disambiguating good/bad versions:
>
> dmesg | grep sky2
sky2 0000:03:00.0: v1.16 addr 0xfa000000 irq 16 Yukon-EC Ultra (0xb4)
rev 2
sky2 eth0: addr XX:XX:XX:XX:XX
sky2 eth0: enabling interface
sky2 eth0: ram buffer 0K
sky2 eth0: disabling interface
-E
---
Eric Preston, RHCA, RHCSS, RHCE
Open Source Software Consultant // Administrator, Developer, Trainer
514-312-7072
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
From: David Miller @ 2007-08-19 23:04 UTC (permalink / raw)
To: felix; +Cc: jeff, netdev, rdreier, linux-kernel, general
In-Reply-To: <8A71B368A89016469F72CD08050AD334018E209C@maui.asicdesigners.com>
From: "Felix Marti" <felix@chelsio.com>
Date: Sun, 19 Aug 2007 12:49:05 -0700
> You're not at all addressing the fact that RDMA does solve the
> memory BW problem and stateless offload doesn't.
It does, I just didn't retort to your claims because they were
so blatantly wrong.
^ permalink raw reply
* RE: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
From: Felix Marti @ 2007-08-19 19:49 UTC (permalink / raw)
To: David Miller; +Cc: jeff, netdev, rdreier, linux-kernel, general
In-Reply-To: <20070819.123212.13769462.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Sunday, August 19, 2007 12:32 PM
> To: Felix Marti
> Cc: sean.hefty@intel.com; netdev@vger.kernel.org; rdreier@cisco.com;
> general@lists.openfabrics.org; linux-kernel@vger.kernel.org;
> jeff@garzik.org
> Subject: Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate
> PS_TCPportsfrom the host TCP port space.
>
> From: "Felix Marti" <felix@chelsio.com>
> Date: Sun, 19 Aug 2007 10:33:31 -0700
>
> > I know that you don't agree that TSO has drawbacks, as outlined by
> > Roland, but its history showing something else: the addition of TSO
> > took a fair amount of time and network performance was erratic for
> > multiple kernel revisions and the TSO code is sprinkled across the
> > network stack.
>
> This thing you call "sprinkled" is a necessity of any hardware
> offload when it is possible for a packet to later get "steered"
> to a device which cannot perform the offload.
>
> Therefore we need a software implementation of TSO so that those
> packets can still get output to the non-TSO-capable device.
>
> We do the same thing for checksum offloading.
>
> And for free we can use the software offloading mechanism to
> get batching to arbitrary network devices, even those which cannot
> do TSO.
>
> What benefits does RDMA infrastructure give to non-RDMA capable
> devices? None? I see, that's great.
>
> And again the TSO bugs and issues are being overstated and, also for
> the second time, these issues are more indicative of my bad
> programming skills then they are of intrinsic issues of TSO. The
> TSO implementation was looking for a good design, and it took me
> a while to find it because I personally suck.
>
> Face it, stateless offloads are always going to be better in the long
> term. And this is proven.
>
> You RDMA folks really do live in some kind of fantasy land.
[Felix Marti] You're not at all addressing the fact that RDMA does solve
the memory BW problem and stateless offload doesn't. Apart from that, I
don't quite understand your argument with respect to the benefits of the
RDMA infrastructure; what benefits does the TSO infrastructure give the
non-TSO capable devices? Isn't the answer none and yet you added TSO
support?! I don't think that the argument is stateless _versus_ stateful
offload both have their advantages and disadvantages. Stateless offload
does help, i.e. TSO/LRO do improve performance in back-to-back
benchmarks. It seems me that _you_ claim that there is no benefit to
statefull offload and that is where we're disagreeing; there is benefit
and i.e. the much lower memory BW requirements is just one example, yet
an important one. We'll probably never agree but it seems to me that
we're asking only for small changes to the software stack and then we
can give the choice to the end users: they can opt for stateless offload
if it fits the performance needs or for statefull offload if their apps
require the extra boost in performance.
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
From: David Miller @ 2007-08-19 19:32 UTC (permalink / raw)
To: felix; +Cc: jeff, netdev, rdreier, linux-kernel, general
In-Reply-To: <8A71B368A89016469F72CD08050AD334018E208F@maui.asicdesigners.com>
From: "Felix Marti" <felix@chelsio.com>
Date: Sun, 19 Aug 2007 10:33:31 -0700
> I know that you don't agree that TSO has drawbacks, as outlined by
> Roland, but its history showing something else: the addition of TSO
> took a fair amount of time and network performance was erratic for
> multiple kernel revisions and the TSO code is sprinkled across the
> network stack.
This thing you call "sprinkled" is a necessity of any hardware
offload when it is possible for a packet to later get "steered"
to a device which cannot perform the offload.
Therefore we need a software implementation of TSO so that those
packets can still get output to the non-TSO-capable device.
We do the same thing for checksum offloading.
And for free we can use the software offloading mechanism to
get batching to arbitrary network devices, even those which cannot
do TSO.
What benefits does RDMA infrastructure give to non-RDMA capable
devices? None? I see, that's great.
And again the TSO bugs and issues are being overstated and, also for
the second time, these issues are more indicative of my bad
programming skills then they are of intrinsic issues of TSO. The
TSO implementation was looking for a good design, and it took me
a while to find it because I personally suck.
Face it, stateless offloads are always going to be better in the long
term. And this is proven.
You RDMA folks really do live in some kind of fantasy land.
^ permalink raw reply
* Re: Marvell 88E8056 gigabit ethernet controller
From: Kevin E @ 2007-08-19 19:13 UTC (permalink / raw)
To: linux-kernel, netdev
In-Reply-To: <20070819113400.12f5570c@localhost>
--- Stephen Hemminger
<shemminger@linux-foundation.org> wrote:
> The driver prints some chip version info at startup,
> that might
> be helpful in disambiguating good/bad versions:
>
> dmesg | grep sky2
Here's the output from the working MB:
sky2 0000:04:00.0: v1.14 addr 0xf8000000 irq 16
Yukon-EC Ultra (0xb4) rev 3
sky2 eth0: addr 00:1a:4d:42:61:46
sky2 eth0: enabling interface
sky2 eth0: ram buffer 0K
sky2 eth0: Link is up at 100 Mbps, full duplex, flow
control both
The broken MB there's no output in dmesg but there is
in /var/log/messages (I just rebooted the machine to
get the output):
Aug 19 14:56:42 www kernel: sky2 0000:04:00.0: v1.14
addr 0xf8000000 irq 16 Yukon-EC Ultra (0xb4) rev 3
Aug 19 14:56:42 www kernel: sky2 eth1: addr
00:1a:4d:82:11:02
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/
^ permalink raw reply
* Re: Marvell 88E8056 gigabit ethernet controller
From: Stephen Hemminger @ 2007-08-19 18:34 UTC (permalink / raw)
To: Eric Preston; +Cc: Kevin E, Willy Tarreau, linux-kernel, netdev
In-Reply-To: <2456F7EB-000C-4B71-B002-64340DD17BA8@linuxmontreal.com>
The driver prints some chip version info at startup, that might
be helpful in disambiguating good/bad versions:
dmesg | grep sky2
^ permalink raw reply
* RE: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
From: Felix Marti @ 2007-08-19 17:33 UTC (permalink / raw)
To: David Miller, sean.hefty; +Cc: netdev, rdreier, jeff, linux-kernel, general
In-Reply-To: <20070819.002337.06589160.davem@davemloft.net>
> -----Original Message-----
> From: general-bounces@lists.openfabrics.org [mailto:general-
> bounces@lists.openfabrics.org] On Behalf Of David Miller
> Sent: Sunday, August 19, 2007 12:24 AM
> To: sean.hefty@intel.com
> Cc: netdev@vger.kernel.org; rdreier@cisco.com;
> general@lists.openfabrics.org; linux-kernel@vger.kernel.org;
> jeff@garzik.org
> Subject: Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate
> PS_TCPportsfrom the host TCP port space.
>
> From: "Sean Hefty" <sean.hefty@intel.com>
> Date: Sun, 19 Aug 2007 00:01:07 -0700
>
> > Millions of Infiniband ports are in operation today. Over 25% of
the
> top 500
> > supercomputers use Infiniband. The formation of the OpenFabrics
> Alliance was
> > pushed and has been continuously funded by an RDMA customer - the US
> National
> > Labs. RDMA technologies are backed by Cisco, IBM, Intel, QLogic,
> Sun, Voltaire,
> > Mellanox, NetApp, AMD, Dell, HP, Oracle, Unisys, Emulex, Hitachi,
> NEC, Fujitsu,
> > LSI, SGI, Sandia, and at least two dozen other companies. IDC
> expects
> > Infiniband adapter revenue to triple between 2006 and 2011, and
> switch revenue
> > to increase six-fold (combined revenues of 1 billion).
>
> Scale these numbers with reality and usage.
>
> These vendors pour in huge amounts of money into a relatively small
> number of extremely large cluster installations. Besides the folks
> doing nuke and whole-earth simulations at some government lab, nobody
> cares. And part of the investment is not being done wholly for smart
> economic reasons, but also largely publicity purposes.
>
> So present your great Infiniband numbers with that being admitted up
> front, ok?
>
> It's relevance to Linux as a general purpose operating system that
> should be "good enough" for %99 of the world is close to NIL.
>
> People have been pouring tons of money and research into doing stupid
> things to make clusters go fast, and in such a way that make zero
> sense for general purpose operating systems, for ages. RDMA is just
> one such example.
[Felix Marti] Ouch, and I believed linux to be a leading edge OS,
scaling from small embedded systems to hundreds of CPUs and hence
I assumed that the same 'scalability' applies to the network subsystem.
>
> BTW, I find it ironic that you mention memory bandwidth as a retort,
> as Roland's favorite stateless offload devil, TSO, deals explicity
> with lowering the per-packet BUS bandwidth usage of TCP. LRO
> offloading does likewise.
[Felix Marti] Aren't you confusing memory and bus BW here? - RDMA
enables DMA from/to application buffers removing the user-to-kernel/
kernel-to-user memory copy with is a significant overhead at the
rates we're talking about: memory copy at 20Gbps (10Gbps in and 10Gbps
out) requires 60Gbps of BW on most common platforms. So, receiving and
transmitting at 10Gbps with LRO and TSO requires 80Gbps of system
memory BW (which is beyond what most systems can do) whereas RDMA can
do with 20Gbps!
In addition, BUS improvements are really not significant (nor are buses
the bottleneck anymore with wide availability of PCI-E >= x8); TSO
avoids
the DMA of a bunch of network headers... a typical example of stateless
offload - improving performance by a few percent while offload
technologies
provide system improvements of hundreds of percent.
I know that you don't agree that TSO has drawbacks, as outlined by
Roland,
but its history showing something else: the addition of TSO took a fair
amount of time and network performance was erratic for multiple kernel
revisions and the TSO code is sprinkled across the network stack. It is
an
example of an intrusive 'improvement' whereas Steve (who started this
thread) is asking for a relatively small change (decoupling the 4-tuple
allocation from the socket). As Steve has outlined, your refusal of the
change requires RDMA users to work around the issue which pushes the
issue to the end-users and thus slowing down the acceptance of the
technology leading to a chicken-and-egg problem: you only care if there
are lots of users but you make it hard to use the technology in the
first
place, clever ;)
> _______________________________________________
> general mailing list
> general@lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-
> general
^ permalink raw reply
* Re: Marvell 88E8056 gigabit ethernet controller
From: Kevin E @ 2007-08-19 16:42 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Willy Tarreau, linux-kernel, netdev
In-Reply-To: <20070819093221.4d3291e9@freepuppy.rosehill.hemminger.net>
--- Stephen Hemminger
<shemminger@linux-foundation.org> wrote:
> The working board has a different version of the
> Marvell chip:
>
> $ grep Marvell working-MB
> 04:00.0 Ethernet controller: Marvell Technology
> Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller
> (rev 14)
> $ grep Marvell broken-MB
> 04:00.0 Ethernet controller: Marvell Technology
> Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller
> (rev 12)
>
> Not sure if that completely explains the problem
> because the broken chip on my
> system is:
> 06:00.0 Ethernet controller: Marvell Technology
> Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller
> (rev 14)
>
> I don't know what the differences are between
> versions.
Since I have a rev 14 that works and you have a rev 14
that doesn't work, is there any other info I can
provide to you that would maybe help in figuring out
how you can get your board working?
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/
^ permalink raw reply
* Re: Marvell 88E8056 gigabit ethernet controller
From: Stephen Hemminger @ 2007-08-19 16:32 UTC (permalink / raw)
To: Kevin E; +Cc: Willy Tarreau, linux-kernel, netdev
In-Reply-To: <283388.84897.qm@web38905.mail.mud.yahoo.com>
On Sat, 18 Aug 2007 06:59:08 -0700 (PDT)
Kevin E <kevin360@yahoo.com> wrote:
> --- Willy Tarreau <w@1wt.eu> wrote:
>
> > OK, in this trace, both controllers are on the same
> > bus. The broken
> > one has 'Capabilities: [100] Advanced Error
> > Reporting' the other
> > does not have, and the bridge to this bus has two
> > more capabilities :
> > 'Capabilities: [100] Virtual Channel' and
> > 'Capabilities: [180] Unknown (5)'.
> >
> > I don't know whether it can jutify a different
> > behaviour. Also, maybe this
> > is caused by a minuscule difference in the BIOS
> > setup ?
>
The working board has a different version of the Marvell chip:
$ grep Marvell working-MB
04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 14)
$ grep Marvell broken-MB
04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12)
Not sure if that completely explains the problem because the broken chip on my
system is:
06:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 14)
I don't know what the differences are between versions.
^ permalink raw reply
* The mess that is SIGPIPE
From: linux @ 2007-08-19 12:00 UTC (permalink / raw)
To: netdev
I noticed that FreeBSD has a useful SOL_SOCKET option, SO_NOSIGPIPE, which
is a "sticky" version of MSG_NOSIGNAL. Particularly useful for libraries,
it disables SIGPIPE on a particular socket without disabling it globally.
Anyway, this led me to look at the implementation of SIGPIPE and
MSG_NOSIGNAL and... it's a bit of a mess. Some places honor
MSG_NOSIGNAL, but there are a lot of code paths that don't appear to.
So I started thinking about a cleanup...
Currently, SIGPIPE is sent from dozens of places that return EPIPE.
What if they could all be deleted and just a few system calls: write(),
writev(), send(), sendto() and sendmsg() (oh, yes, and sendfile())
could check for EPIPE from the VFS calls they make and generate SIGPIPE
appropriately?
The only thing is figuring out where in the call chain to put it.
sys_send()
-> sys_sendto()
-> sock_sendmsg()
-> __sock_sendmsg()
-> sock->ops->sendmsg
sys_write()
-> vfs_write()
-> do_sync_write
-> filp->f_op->aio_write
-> sock_aio_write()
-> do_sock_write()
-> __sock_(sendmsg()
sys_writev()
-> vfs_writev()
-> do_readv_writev()
-> do_loop_readv_writev()
-> file->f_op->write
-> ????
-> sock_aio_write()
-> do_sock_write()
-> __sock_(sendmsg()
kernel_sendmsg() also calls sock_sendmsg(), and it would save a bunch
of fiddling with MSG_NOSIGNAL if kernel_sendmsg() never generated signals.
That implies that the check should be at the sys_sendto() layer or higher.
Anyway, looking into implementing this, I found a zillion places where
the logic looked a little unclear, such as OCFS2 code. I'm not convinced
that a bug there can't generate SIGPIPE unexpectedly.
Anyway, before I tackle this rewrite, I'd like to ask if someone knows
what the code is *supposed* to be doing, and can confirm that SIGPIPE
should be generated if and only if the write is done by a user-level
system call that can return EPIPE. So all the buried network file
systems should never generate it. Is that right?
Thanks for the insights.
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP portsfrom the host TCP port space.
From: David Miller @ 2007-08-19 7:23 UTC (permalink / raw)
To: sean.hefty; +Cc: rdreier, jeff, netdev, linux-kernel, general
In-Reply-To: <000001c7e22e$b7b90f00$29c8180a@amr.corp.intel.com>
From: "Sean Hefty" <sean.hefty@intel.com>
Date: Sun, 19 Aug 2007 00:01:07 -0700
> Millions of Infiniband ports are in operation today. Over 25% of the top 500
> supercomputers use Infiniband. The formation of the OpenFabrics Alliance was
> pushed and has been continuously funded by an RDMA customer - the US National
> Labs. RDMA technologies are backed by Cisco, IBM, Intel, QLogic, Sun, Voltaire,
> Mellanox, NetApp, AMD, Dell, HP, Oracle, Unisys, Emulex, Hitachi, NEC, Fujitsu,
> LSI, SGI, Sandia, and at least two dozen other companies. IDC expects
> Infiniband adapter revenue to triple between 2006 and 2011, and switch revenue
> to increase six-fold (combined revenues of 1 billion).
Scale these numbers with reality and usage.
These vendors pour in huge amounts of money into a relatively small
number of extremely large cluster installations. Besides the folks
doing nuke and whole-earth simulations at some government lab, nobody
cares. And part of the investment is not being done wholly for smart
economic reasons, but also largely publicity purposes.
So present your great Infiniband numbers with that being admitted up
front, ok?
It's relevance to Linux as a general purpose operating system that
should be "good enough" for %99 of the world is close to NIL.
People have been pouring tons of money and research into doing stupid
things to make clusters go fast, and in such a way that make zero
sense for general purpose operating systems, for ages. RDMA is just
one such example.
BTW, I find it ironic that you mention memory bandwidth as a retort,
as Roland's favorite stateless offload devil, TSO, deals explicity
with lowering the per-packet BUS bandwidth usage of TCP. LRO
offloading does likewise.
^ permalink raw reply
* RE: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP portsfrom the host TCP port space.
From: Sean Hefty @ 2007-08-19 7:01 UTC (permalink / raw)
To: 'David Miller', rdreier; +Cc: netdev, general, linux-kernel, jeff
In-Reply-To: <20070817.234405.66176298.davem@davemloft.net>
>Just be realistic and accept that RDMA is a point in time solution,
>and like any other such technology takes flexibility away from users.
All technologies are just point in time solutions. While management is
important, shouldn't the customers decide how important it is relative to their
problems? Whether some future technology will be better matters little if a
problem needs to be solved today.
>If you can't see that this is the future, you have my condolences.
>Because frankly, the signs are all around that this is where things
>are going.
Adding a bazillion cores to a processor doesn't do a thing to help memory
bandwidth.
Millions of Infiniband ports are in operation today. Over 25% of the top 500
supercomputers use Infiniband. The formation of the OpenFabrics Alliance was
pushed and has been continuously funded by an RDMA customer - the US National
Labs. RDMA technologies are backed by Cisco, IBM, Intel, QLogic, Sun, Voltaire,
Mellanox, NetApp, AMD, Dell, HP, Oracle, Unisys, Emulex, Hitachi, NEC, Fujitsu,
LSI, SGI, Sandia, and at least two dozen other companies. IDC expects
Infiniband adapter revenue to triple between 2006 and 2011, and switch revenue
to increase six-fold (combined revenues of 1 billion).
Customers see real benefits using channel based architectures. Do all customers
need it? Of course not. Is it a niche? Yes, but I would say that about any
10+ gig network. That doesn't mean that it hasn't become essential for some
customers.
- Sean
^ permalink raw reply
* Re: [RFT] r8169 changes against 2.6.23-rc3
From: Bruce Cole @ 2007-08-19 2:41 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, bacole, David Gundersen
In-Reply-To: <20070818100701.GA20703@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
> The latest serie of r8169 changes is available against 2.6.23-rc3 as:
> http://www.fr.zoreil.com/people/francois/misc/20070818-2.6.23-rc3-r8169-test.patch
>
> or (tarball sits one level higher):
>
> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.23-rc3/r8169-20070818/
>
> or (rebase prone branch)
>
I applied these patches (except for the eeprom read support patch) to
2.6.23-rc3, and it did not fix the TX performance problem. The
busy-wait workaround is still required to dramatically improve
performance. I experimented some more and found that ndelay(10) is a
sufficient delay within the for loop, as David Gundersen suggested.
With some diagnostic code, I can see that when there is a NPQ problem,
the busy wait calls ndelay(10) 4 or 5 times before the NPQ bit clears,
and meanwhile the TX queue only contains a low number of entries (2 to 5
typically). This is a bit surprising, I would have guessed the root
problem related to the queue filling up.
I was then suspicious that maybe there was an issue with TX interrupts
not being serviced in a timely manner due to the NAPI RX support, but
making the TX processing work without NAPI did not solve things.
I took a look at tcpdump output from both the sender&receiver and found
that when there is a problem, the sender is apparently delaying
transmission of packets. TCP then retransmits, and duplicate TCP
sequences arrive at the receiver at that later time.
So it seems that when the driver tries to queue a packet while the
controller is busy processing the queue, the newly queued packet does
not get noticed by the controller (until further packet activity occurs).
Perhaps there is a problem with the memory barriers when adding to the
TX queue, but I'm a newbie on linux kernel memory barriers.
tcpdump sample follows, with the realtek interface on the sending side.
In the sample, notice that the data at sequence #1429358 is
retransmitted by the sender after .3 seconds, but the receiver receives
both copies at basically the same time (delayed by approximately .3
seconds).
Sender:
13:42:10.325958 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1414878:1416326(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:10.325979 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1416326:1417774(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:10.325999 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1417774:1419222(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:10.326018 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1419222:1420670(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:10.326036 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1420670:1422118(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:10.326056 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1422118:1423566(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:10.326076 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1423566:1425014(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:10.326094 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1425014:1426462(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:10.326114 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1426462:1427910(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:10.326565 IP 192.168.1.12.60994 > 192.168.1.11.netbios-ssn: . ack
1417774 win 2056 <nop,nop,timestamp 4346009 226653029>
13:42:10.326607 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1427910:1429358 (1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:10.326614 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1429358:1430806(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:10.326620 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: P
1430806:1431325(519) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:10.326626 IP 192.168.1.12.60994 > 192.168.1.11.netbios-ssn: . ack
1427910 win 1907 <nop,nop,timestamp 4346009 226653029>
13:42:10.366646 IP 192.168.1.12.60994 > 192.168.1.11.netbios-ssn: . ack
1429358 win 2056 <nop,nop,timestamp 4346050 226653029>
13:42:10.652691 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1429358:1430806(1448) ack 5775 win 54 <nop,nop,timestamp 226653356
4346050> NBT Session Packet: Session Message
13:42:10.653636 IP 192.168.1.12.60994 > 192.168.1.11.netbios-ssn: . ack
1430806 win 2056 <nop,nop,timestamp 4346337 226653029>
13:42:10.653671 IP 192.168.1.12.60994 > 192.168.1.11.netbios-ssn: . ack
1431325 win 2056 <nop,nop,timestamp 4346337 226653029>
13:42:10.653698 IP 192.168.1.12.60994 > 192.168.1.11.netbios-ssn: . ack
1431325 win 2056 <nop,nop,timestamp 4346337 226653029,nop,nop,sack 1
{1429358:1430806}>
Receiver:
13:42:11.516820 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1414878:1416326(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:11.516841 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1416326:1417774(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:11.516856 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1417774:1419222(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:11.516881 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1419222:1420670(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:11.516895 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1420670:1422118(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:11.516923 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1422118:1423566(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:11.516938 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1423566:1425014(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:11.516952 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1425014:1426462(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:11.516975 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1426462:1427910(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:11.517148 IP 192.168.1.12.60994 > 192.168.1.11.netbios-ssn: . ack
1417774 win 2056 <nop,nop,timestamp 4346009 226653029>
13:42:11.517173 IP 192.168.1.12.60994 > 192.168.1.11.netbios-ssn: . ack
1427910 win 1907 <nop,nop,timestamp 4346009 226653029>
13:42:11.517471 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1427910:1429358(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:11.557260 IP 192.168.1.12.60994 > 192.168.1.11.netbios-ssn: . ack
1429358 win 2056 <nop,nop,timestamp 4346050 226653029>
13:42:11.843655 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1429358:1430806(1448) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:11.843704 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: P
1430806:1431325(519) ack 5775 win 54 <nop,nop,timestamp 226653029
4346009> NBT Session Packet: Session Message
13:42:11.843720 IP 192.168.1.11.netbios-ssn > 192.168.1.12.60994: .
1429358:1430806(1448) ack 5775 win 54 <nop,nop,timestamp 226653356
4346050> NBT Session Packet: Session Message
13:42:11.844342 IP 192.168.1.12.60994 > 192.168.1.11.netbios-ssn: . ack
1430806 win 2056 <nop,nop,timestamp 4346337 226653029>
13:42:11.844366 IP 192.168.1.12.60994 > 192.168.1.11.netbios-ssn: . ack
1431325 win 2056 <nop,nop,timestamp 4346337 226653029>
13:42:11.844383 IP 192.168.1.12.60994 > 192.168.1.11.netbios-ssn: . ack
1431325 win 2056 <nop,nop,timestamp 4346337 226653029,nop,nop,sack 1
{1429358:1430806}>
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Paul E. McKenney @ 2007-08-18 23:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Satyam Sharma, Christoph Lameter, Herbert Xu, Nick Piggin,
Paul Mackerras, Segher Boessenkool, heiko.carstens, horms,
linux-kernel, rpjday, ak, netdev, cfriesen, akpm, jesper.juhl,
linux-arch, zlynx, schwidefsky, Chris Snook, davem, wensong,
wjiang
In-Reply-To: <alpine.LFD.0.999.0708181526270.30176@woody.linux-foundation.org>
On Sat, Aug 18, 2007 at 03:41:13PM -0700, Linus Torvalds wrote:
>
>
> On Sat, 18 Aug 2007, Paul E. McKenney wrote:
> >
> > One of the gcc guys claimed that he thought that the two-instruction
> > sequence would be faster on some x86 machines. I pointed out that
> > there might be a concern about code size. I chose not to point out
> > that people might also care about the other x86 machines. ;-)
>
> Some (very few) x86 uarchs do tend to prefer "load-store" like code
> generation, and doing a "mov [mem],reg + op reg" instead of "op [mem]" can
> actually be faster on some of them. Not any that are relevant today,
> though.
;-)
> Also, that has nothing to do with volatile, and should be controlled by
> optimization flags (like -mtune). In fact, I thought there was a separate
> flag to do that (ie something like "-mload-store"), but I can't find it,
> so maybe that's just my fevered brain..
Good point, will suggest this if the need arises.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Linus Torvalds @ 2007-08-18 22:41 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Satyam Sharma, Christoph Lameter, Herbert Xu, Nick Piggin,
Paul Mackerras, Segher Boessenkool, heiko.carstens, horms,
linux-kernel, rpjday, ak, netdev, cfriesen, akpm, jesper.juhl,
linux-arch, zlynx, schwidefsky, Chris Snook, davem, wensong,
wjiang
In-Reply-To: <20070818215409.GC7628@linux.vnet.ibm.com>
On Sat, 18 Aug 2007, Paul E. McKenney wrote:
>
> One of the gcc guys claimed that he thought that the two-instruction
> sequence would be faster on some x86 machines. I pointed out that
> there might be a concern about code size. I chose not to point out
> that people might also care about the other x86 machines. ;-)
Some (very few) x86 uarchs do tend to prefer "load-store" like code
generation, and doing a "mov [mem],reg + op reg" instead of "op [mem]" can
actually be faster on some of them. Not any that are relevant today,
though.
Also, that has nothing to do with volatile, and should be controlled by
optimization flags (like -mtune). In fact, I thought there was a separate
flag to do that (ie something like "-mload-store"), but I can't find it,
so maybe that's just my fevered brain..
Linus
^ permalink raw reply
* Re: [PATCH] lockdep: annotate rcu_read_{,un}lock()
From: Paul E. McKenney @ 2007-08-18 22:03 UTC (permalink / raw)
To: Corey Minyard
Cc: Peter Zijlstra, Ingo Molnar, herbert, 123.oleg, netdev,
linux-kernel, David Miller, Daniel Walker, josht
In-Reply-To: <46C5ED69.6060604@acm.org>
On Fri, Aug 17, 2007 at 01:48:09PM -0500, Corey Minyard wrote:
> 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,
> >>>>how about doing something like this:
> >>>>
> >>>This will break when rcu_read_lock() and rcu_read_unlock() are invoked
> >>>from NMI/SMI handlers -- the raw_local_irq_save() in lock_acquire() will
> >>>not mask NMIs or SMIs.
> >>>
> >>>One approach would be to check for being in an NMI/SMI handler, and
> >>>to avoid calling lock_acquire() and lock_release() in those cases.
> >>>
> >>It seems:
> >>
> >>#define nmi_enter() do { lockdep_off(); __irq_enter(); } while
> >>(0)
> >>#define nmi_exit() do { __irq_exit(); lockdep_on(); } while (0)
> >>
> >>Should make it all work out just fine. (for NMIs at least, /me fully
> >>ignorant of the workings of SMIs)
> >>
> >
> >Very good point, at least for NMIs on i386 and x86_64. Can't say that I
> >know much about SMIs myself. Or about whatever equivalents to NMIs and
> >SMIs might exist on other platforms. :-/ Of course, the other platforms
> >could be handled by making the RCU lockdep operate only on i386 and x86_64
> >if required.
> >
> >Corey, any advice on SMI handlers? Is there something like nmi_enter()
> >and nmi_exit() that allows disabing lockdep?
> >
> You will certainly need something like nmi_enter() and nmi_exit() for
> SMIs, since they can occur at any time like NMIs. As far as anything
> else, you just have to be extremely careful and remember that it can
> occur anyplace. But you already know that :).
So we would need to create an smi_enter() and smi_exit() an place them
appropriately. Any preferences?
> It would be nice if the PowerPC board vendors would tie watchdog
> pretimeouts and some type of timer into the SMI input. It would make
> debugging certain problems much easier. And all those Marvell bridge
> chips have a watchdog pretimeout and I haven't seen any board vendor
> wire it up :(.
Can't say that I have much influence over them, but I must agree
that debuggability is a very good thing!
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Paul E. McKenney @ 2007-08-18 21:56 UTC (permalink / raw)
To: Christoph Lameter
Cc: Herbert Xu, Linus Torvalds, Nick Piggin, Paul Mackerras,
Segher Boessenkool, heiko.carstens, horms, linux-kernel, rpjday,
ak, netdev, cfriesen, akpm, jesper.juhl, linux-arch, zlynx,
satyam, schwidefsky, Chris Snook, davem, wensong, wjiang
In-Reply-To: <Pine.LNX.4.64.0708171817050.15427@schroedinger.engr.sgi.com>
On Fri, Aug 17, 2007 at 06:24:15PM -0700, 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 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 fixed!
> >
> > Well, just got done re-opening it for the third time. And a local
> > gcc community member advised me not to give up too easily. But I
> > must admit that I am impressed with the speed that it was identified
> > as duplicate.
> >
> > Should be entertaining! ;-)
>
> Right. ROTFL... volatile actually breaks atomic_t instead of making it
> safe. x++ becomes a register load, increment and a register store. Without
> volatile we can increment the memory directly. It seems that volatile
> requires that the variable is loaded into a register first and then
> operated upon. Understandable when you think about volatile being used to
> access memory mapped I/O registers where a RMW operation could be
> problematic.
>
> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
Yep. The initial reaction was in fact to close my bug as a duplicate
of 3506. But I was not asking for atomicity, but rather for smaller
code to be generated, so I reopened it.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Paul E. McKenney @ 2007-08-18 21:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Satyam Sharma, Christoph Lameter, Herbert Xu, Nick Piggin,
Paul Mackerras, Segher Boessenkool, heiko.carstens, horms,
linux-kernel, rpjday, ak, netdev, cfriesen, akpm, jesper.juhl,
linux-arch, zlynx, schwidefsky, Chris Snook, davem, wensong,
wjiang
In-Reply-To: <alpine.LFD.0.999.0708172110400.30176@woody.linux-foundation.org>
On Fri, Aug 17, 2007 at 09:13:35PM -0700, Linus Torvalds wrote:
>
>
> 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 register is stupid and pointless, when you could just
> do it as a regular memory-operand to the cmp instruction.
>
> And as far as the compiler is concerned, the problem is the 100% same:
> combining operations with the volatile memop.
>
> The fact is, a compiler that thinks that
>
> movl mem,reg
> cmpl $val,reg
>
> is any better than
>
> cmpl $val,mem
>
> is just not a very good compiler. But when talking about "volatile",
> that's exactly what ytou always get (and always have gotten - this is
> not a regression, and I doubt gcc is alone in this).
One of the gcc guys claimed that he thought that the two-instruction
sequence would be faster on some x86 machines. I pointed out that
there might be a concern about code size. I chose not to point out
that people might also care about the other x86 machines. ;-)
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 8/9] define global BIT macro
From: Randy Dunlap @ 2007-08-18 18:15 UTC (permalink / raw)
To: Jiri Slaby
Cc: Andrew Morton, linux-kernel, source, dougthompson,
bluesmoke-devel, dtor, linux-input, netdev, James.Bottomley,
linux-scsi, gtolstolytkin, vitalywool, dsaxena, ralf, linux-mips,
mchehab, video4linux-list, jbenc, flamingice, linux-wireless
In-Reply-To: <46C728CB.6060102@gmail.com>
Jiri Slaby wrote:
> Randy Dunlap napsal(a):
>> On Sat, 18 Aug 2007 11:44:12 +0200 (CEST) Jiri Slaby wrote:
>>
>>> define global BIT macro
>>>
>>> move all local BIT defines to the new globally define macro.
>>>
>>> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
>>>
>>> ---
>>>
>>> include/linux/bitops.h | 1 +
>>> include/video/sstfb.h | 1 -
>>> include/video/tdfx.h | 2 --
>>> net/mac80211/ieee80211_i.h | 2 --
>>> 18 files changed, 1 insertions(+), 37 deletions(-)
>>>
>>> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
>>> index 3255b06..a57b81f 100644
>>> --- a/include/linux/bitops.h
>>> +++ b/include/linux/bitops.h
>>> @@ -3,6 +3,7 @@
>>> #include <asm/types.h>
>>>
>>> #ifdef __KERNEL__
>>> +#define BIT(nr) (1UL << (nr))
>>> #define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG))
>>> #define BIT_WORD(nr) ((nr) / BITS_PER_LONG)
>>> #define BITS_TO_TYPE(nr, t) (((nr)+(t)-1)/(t))
>>
>> So users of the BIT() macro in include/linux/input.h can be
>> changed to use the global BIT_MASK() macro...
>> and the former can be removed.
>
> I'm afraid I don't understand you. Maybe, you are writing about changes done in
> patch no. 7 [1], which didn't go through to the lkml?
>
> [1]
> http://www.fi.muni.cz/~xslaby/sklad/07-get-rid-of-input-bit-duplicate-defines.patch
Exactly. Thanks.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 8/9] define global BIT macro
From: Jiri Slaby @ 2007-08-18 17:13 UTC (permalink / raw)
To: Randy Dunlap
Cc: Andrew Morton, linux-kernel, source, dougthompson,
bluesmoke-devel, dtor, linux-input, netdev, James.Bottomley,
linux-scsi, gtolstolytkin, vitalywool, dsaxena, ralf, linux-mips,
mchehab, video4linux-list, jbenc, flamingice, linux-wireless
In-Reply-To: <20070818094602.0ea69c27.randy.dunlap@oracle.com>
Randy Dunlap napsal(a):
> On Sat, 18 Aug 2007 11:44:12 +0200 (CEST) Jiri Slaby wrote:
>
>> define global BIT macro
>>
>> move all local BIT defines to the new globally define macro.
>>
>> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
>>
>> ---
>>
>> include/linux/bitops.h | 1 +
>> include/video/sstfb.h | 1 -
>> include/video/tdfx.h | 2 --
>> net/mac80211/ieee80211_i.h | 2 --
>> 18 files changed, 1 insertions(+), 37 deletions(-)
>>
>> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
>> index 3255b06..a57b81f 100644
>> --- a/include/linux/bitops.h
>> +++ b/include/linux/bitops.h
>> @@ -3,6 +3,7 @@
>> #include <asm/types.h>
>>
>> #ifdef __KERNEL__
>> +#define BIT(nr) (1UL << (nr))
>> #define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG))
>> #define BIT_WORD(nr) ((nr) / BITS_PER_LONG)
>> #define BITS_TO_TYPE(nr, t) (((nr)+(t)-1)/(t))
>
>
> So users of the BIT() macro in include/linux/input.h can be
> changed to use the global BIT_MASK() macro...
> and the former can be removed.
I'm afraid I don't understand you. Maybe, you are writing about changes done in
patch no. 7 [1], which didn't go through to the lkml?
[1]
http://www.fi.muni.cz/~xslaby/sklad/07-get-rid-of-input-bit-duplicate-defines.patch
thanks,
--
Jiri Slaby (jirislaby@gmail.com)
Faculty of Informatics, Masaryk University
^ permalink raw reply
* Re: [PATCH 8/9] define global BIT macro
From: Randy Dunlap @ 2007-08-18 16:46 UTC (permalink / raw)
To: Jiri Slaby
Cc: Andrew Morton, linux-kernel, source, dougthompson,
bluesmoke-devel, dtor, linux-input, netdev, James.Bottomley,
linux-scsi, gtolstolytkin, vitalywool, dsaxena, ralf, linux-mips,
mchehab, video4linux-list, jbenc, flamingice, linux-wireless
In-Reply-To: <428714662539710215@wsc.cz>
On Sat, 18 Aug 2007 11:44:12 +0200 (CEST) Jiri Slaby wrote:
> define global BIT macro
>
> move all local BIT defines to the new globally define macro.
>
> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
>
> ---
>
> include/linux/bitops.h | 1 +
> include/video/sstfb.h | 1 -
> include/video/tdfx.h | 2 --
> net/mac80211/ieee80211_i.h | 2 --
> 18 files changed, 1 insertions(+), 37 deletions(-)
>
> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
> index 3255b06..a57b81f 100644
> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@ -3,6 +3,7 @@
> #include <asm/types.h>
>
> #ifdef __KERNEL__
> +#define BIT(nr) (1UL << (nr))
> #define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG))
> #define BIT_WORD(nr) ((nr) / BITS_PER_LONG)
> #define BITS_TO_TYPE(nr, t) (((nr)+(t)-1)/(t))
So users of the BIT() macro in include/linux/input.h can be
changed to use the global BIT_MASK() macro...
and the former can be removed.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox