* Semantics of SO_REUSEADDR and P2P TCP NAT traversal
From: Paul Clark @ 2007-10-02 16:37 UTC (permalink / raw)
To: netdev
Folks,
I posted this query to LKML last week but have had no response, but I've
since found that Ilya Pashkovsky raised the same issue - and supplied
what appears to be a good patch for it - here back in 2004:
http://marc.info/?l=linux-netdev&m=110312719803402&w=2
Ilya's patch didn't get accepted either, and after I contacted him last
week he pointed me to linux-netdev to see if I could get the question
reopened. I think I've answered the objections in earlier threads
below, but I'm open to persuasion!
Headline summary: The behaviour of Linux around port reuse with bind()
and listen() is both inconsistent and overly restrictive, and prevents
simple implementation of TCP NAT traversal methods which are currently
being standardised by the IETF BEHAVE WG.
--
I'm working on implementing a TCP NAT traversal scheme for a P2P
application, similar to that described in:
http://www.brynosaurus.com/pub/net/p2pnat/
and also in
http://tools.ietf.org/html/draft-ietf-behave-p2p-state-03 [3.4]
The idea in using TCP is to provide a P2P file transfer architecture
which retains the benefits of TCP's windowing and congestion control and
hence is more efficient and network-friendly than the current UDP-based
ones.
NAT 'hole punching' for TCP essentially depends on the two peers
more-or-less simultaneously opening mirrored connections to each other,
and hoping that the intervening NATs' 'conntrack'-equivalents will allow
the SYN exchange. If the connections are _really_ simultaneous, so that
the SYNs cross on the wire, this might also trigger a simultaneous-open
transition on the peers.
To make this work, the peers have to both be initiating from the same
port they are listening on, so that their SYNs match. This would
apparently break the "4-tuples uniquely identify a socket" rule at each
end, but this is transient - only one of the two sockets at each end
will end up connected.
Ford et al. say in the above paper that the main issue with implementing
this through the BSD sockets API is the ability to have both a
listen()ing socket and an outgoing connection bound to the same local
port, but that SO_REUSEADDR (and SO_REUSEPORT, where defined) comes to
our rescue. However my initial implementation of this fails with
EADDRINUSE (simplified psuedo-code):
==
fd_listen = socket(PF_INET, SOCK_STREAM, 0)
setsockopt(fd_listen, SOL_SOCKET, SO_REUSEADDR, 1)
bind(fd_listen, sockaddr_in(127.0.0.1, 11111))
listen(fd_listen)
fd_out = socket(PF_INET, SOCK_STREAM, 0)
setsockopt(fd_out, SOL_SOCKET, SO_REUSEADDR, 1)
bind(fd_out, socketaddr_in(127.0.0.1, 11111)) => EADDRINUSE
==
Just to note, it also fails in the same way with INADDR_ANY or a real
interface IP in either bind().
However, if I bind() the outgoing socket first, it is OK:
==
fd_out = socket(PF_INET, SOCK_STREAM, 0)
setsockopt(fd_out, SOL_SOCKET, SO_REUSEADDR, 1)
bind(fd_out, socketaddr_in(127.0.0.1, 11111))
fd_listen = socket(PF_INET, SOCK_STREAM, 0)
setsockopt(fd_listen, SOL_SOCKET, SO_REUSEADDR, 1)
bind(fd_listen, sockaddr_in(127.0.0.1, 11111)) // OK
listen(fd_listen) // OK
==
Looking at the kernel code in net/ipv4/inet_connection_sock.c,
inet_csk_bind_conflict() and inet_csk_get_port(), this is to be expected
- the duplicate bind() only conflicts if there is _already_ a TCP_LISTEN
socket bound. I guess the intention was to prevent hijacking of
existing listen() sockets, as was discussed when this subject last came
up, in a very similar context:
http://uwsg.iu.edu/hypermail/linux/kernel/0102.0/0214.html
However, the order-dependent behaviour, breaks rule (2) expressed in
include/ipv4/inet_hashtables.c, assuming you read it as an invariant,
rather than a precondition:
* 2) If all sockets have sk->sk_reuse set, and none of them are in
* TCP_LISTEN state, the port may be shared.
If you look a Bryan Ford's NAT test code at
http://midcom-p2p.sourceforge.net/natcheck.c
you'll see that he also bind()s all his sockets before listen()ing,
which I guess is why it works. It is possible to use the
bind-outgoing-before-listening variety in simple tests like these, but
for a real application one would ideally want the listen() socket nailed
up permanently and be able to create new outgoing sockets to the
rendevous server or peers at will. I guess it might be possible to
create a pool of bound outgoing sockets and then the listen(), and tear
down and restart everything when the pool runs out, but that seems
pretty messy.
So, at the end of all this, I have two questions:
(1) Given there is a valid use of this for TCP hole punching, should not
the rule be - as suggested by Paul D. Smith in the post above - that you
cannot have two listen()s on the same port, rather than (as now) one
listen() and any other bind()? Apparently this is the semantics of
Solaris, FreeBSD and Windows, but I have not verified this... I noted
AC's objection around NFS at the time, but that seems to apply only to
UDP, and these rules are specific to TCP state - UDP could remain
stricter, if required.
(2) The current order-dependent behaviour seems inconsistent with the
implied invariant rule that a listen() is exclusive on that port. We
could make use of the present behaviour, but it feels like a bit of a
hack, and of course the worry is that the inconsistency might be 'fixed'
at some point in the future. Do people consider this a bug, or a
feature that is likely to be preserved? (I hope at least if anyone
thinks about fixing this, they may discover there someone using it!)
CC's helpful, but I will read list replies.
Many thanks
Paul
--
Paul Clark
Packet Ship Technologies Limited
www.packetship.com
^ permalink raw reply
* Re: [patch] dm9601: Fix receive MTU
From: Jeff Garzik @ 2007-10-02 17:01 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: netdev
In-Reply-To: <87myv35aoo.fsf@macbook.be.48ers.dk>
Peter Korsgaard wrote:
> Please apply to 2.6.23.
> ---
> dm9601 didn't take the ethernet header into account when calculating
> RX MTU, causing packets bigger than 1486 to fail.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> ---
> drivers/net/usb/dm9601.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6.23-rc8/drivers/net/usb/dm9601.c
> ===================================================================
> --- linux-2.6.23-rc8.orig/drivers/net/usb/dm9601.c
> +++ linux-2.6.23-rc8/drivers/net/usb/dm9601.c
> @@ -405,7 +405,7 @@
> dev->net->ethtool_ops = &dm9601_ethtool_ops;
> dev->net->hard_header_len += DM_TX_OVERHEAD;
> dev->hard_mtu = dev->net->mtu + dev->net->hard_header_len;
> - dev->rx_urb_size = dev->net->mtu + DM_RX_OVERHEAD;
> + dev->rx_urb_size = dev->net->mtu + ETH_HLEN + DM_RX_OVERHEAD;
applied. in the future, please note (and avoid) a patch formatting
error. As noted in #14 of Documentation/SubmittingPatches, any comments
on the patch like "Please apply to 2.6.23" should go AFTER the patch
description and "---" separator.
Without hand editing, the normal tools everybody uses for importing
patches would delete your "dm9601 didn't take the ethernet header..."
description, leaving only the "Please apply to 2.6.23." part and nothing
else.
I did the hand-editing, but please try to follow the standard patch
format in the future.
^ permalink raw reply
* Re: [PATCH] drivers/net/r8169.c - trivial - add KERN_DEBUG to dprintk and PFX before KERN_ uses
From: Jeff Garzik @ 2007-10-02 16:57 UTC (permalink / raw)
To: Joe Perches; +Cc: Francois Romieu, Andrew Morton, David S. Miller, netdev
In-Reply-To: <1191343038.13170.32.camel@localhost>
Joe Perches wrote:
> Signed-off-by: Joe Perches <joe@perches.com>
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index c921ec3..40019aa 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -44,7 +44,8 @@
> printk( "Assertion failed! %s,%s,%s,line=%d\n", \
> #expr,__FILE__,__FUNCTION__,__LINE__); \
> }
> -#define dprintk(fmt, args...) do { printk(PFX fmt, ## args); } while (0)
> +#define dprintk(fmt, args...) \
> + do { printk(KERN_DEBUG PFX fmt, ## args); } while (0)
> #else
> #define assert(expr) do {} while (0)
> #define dprintk(fmt, args...) do {} while (0)
> @@ -1924,7 +1925,7 @@ static void rtl_hw_start_8169(struct net_device *dev)
>
> if ((tp->mac_version == RTL_GIGA_MAC_VER_02) ||
> (tp->mac_version == RTL_GIGA_MAC_VER_03)) {
> - dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0. "
> + dprintk("Set MAC Reg C+CR Offset 0xE0. "
> "Bit-3 and bit-14 MUST be 1\n");
> tp->cp_cmd |= (1 << 14);
> }
NAK these, the author clearly prefers his debugging output at KERN_INFO
level
> @@ -2289,7 +2290,7 @@ static void rtl8169_reinit_task(struct work_struct *work)
> ret = rtl8169_open(dev);
> if (unlikely(ret < 0)) {
> if (net_ratelimit() && netif_msg_drv(tp)) {
> - printk(PFX KERN_ERR "%s: reinit failure (status = %d)."
> + printk(KERN_ERR PFX "%s: reinit failure (status = %d)."
> " Rescheduling.\n", dev->name, ret);
> }
> rtl8169_schedule_work(dev, rtl8169_reinit_task);
> @@ -2321,7 +2322,7 @@ static void rtl8169_reset_task(struct work_struct *work)
> netif_wake_queue(dev);
> } else {
> if (net_ratelimit() && netif_msg_intr(tp)) {
> - printk(PFX KERN_EMERG "%s: Rx buffers shortage\n",
> + printk(KERN_EMERG PFX "%s: Rx buffers shortage\n",
> dev->name);
> }
these are fixes, and should be in a separate patch
^ permalink raw reply
* Re: [PATCH] mv643xx_eth: Do not modify struct netdev tx_queue_len
From: Jeff Garzik @ 2007-10-02 16:55 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: netdev
In-Reply-To: <20071001230218.GA27461@xyzzy.farnsworth.org>
Dale Farnsworth wrote:
> From: Dale Farnsworth <dale@farnsworth.org>
>
> This driver erroneously zeros dev->tx_queue_len, since
> mp->tx_ring_size has not yet been initialized. Actually,
> the driver shouldn't modify tx_queue_len at all and should
> leave the value set by alloc_etherdev(), currently 1000.
>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> ---
> Jeff, this bug was just reported today, or I would have batched
> it with the one I sent you last week. It's an obvious bugfix,
> so I'm not going to hold it in my queue.
>
> drivers/net/mv643xx_eth.c | 1 -
> 1 file changed, 1 deletion(-)
applied
^ permalink raw reply
* Re: [PATCH 1/2] qla3xxx: bugfix: Add memory barrier before accessing rx completion.
From: Jeff Garzik @ 2007-10-02 16:55 UTC (permalink / raw)
To: Ron Mercer; +Cc: netdev
In-Reply-To: <1191264203681-git-send-email-ron.mercer@qlogic.com>
Ron Mercer wrote:
> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
> ---
> drivers/net/qla3xxx.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
> index 69da95b..c3fe1c7 100755
> --- a/drivers/net/qla3xxx.c
> +++ b/drivers/net/qla3xxx.c
> @@ -2248,6 +2248,7 @@ static int ql_tx_rx_clean(struct ql3_adapter *qdev,
> qdev->rsp_consumer_index) && (work_done < work_to_do)) {
>
> net_rsp = qdev->rsp_current;
> + rmb();
> switch (net_rsp->opcode) {
applied 1-2
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH V6 0/9] net/bonding: ADD IPoIB support for the bonding driver
From: Jeff Garzik @ 2007-10-02 16:52 UTC (permalink / raw)
To: Moni Shoua; +Cc: Jay Vosburgh, netdev, Roland Dreier, OpenFabrics General
In-Reply-To: <470268A2.7080102@gmail.com>
Moni Shoua wrote:
> Jay Vosburgh wrote:
>> ACK patches 3 - 9.
>>
>> Roland, are you comfortable with the IB changes in patches 1 and 2?
>>
>> Jeff, when Roland acks patches 1 and 2, please apply all 9.
>>
>> -J
>
> Hi Jeff,
> Roland acked the IPoIB patches. If you haven't done so already can you please apply them?
> I'm not sure when 2.6.24 is going to open and I'm afraid to miss it.
hrm, I don't see them in my inbox for some reason. can someone bounce
them to me? or give me a git tree to pull from?
Jeff
^ permalink raw reply
* [PATCH] drivers/net/r8169.c - trivial - add KERN_DEBUG to dprintk and PFX before KERN_ uses
From: Joe Perches @ 2007-10-02 16:37 UTC (permalink / raw)
To: Francois Romieu; +Cc: Andrew Morton, David S. Miller, Jeff Garzik, netdev
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index c921ec3..40019aa 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -44,7 +44,8 @@
printk( "Assertion failed! %s,%s,%s,line=%d\n", \
#expr,__FILE__,__FUNCTION__,__LINE__); \
}
-#define dprintk(fmt, args...) do { printk(PFX fmt, ## args); } while (0)
+#define dprintk(fmt, args...) \
+ do { printk(KERN_DEBUG PFX fmt, ## args); } while (0)
#else
#define assert(expr) do {} while (0)
#define dprintk(fmt, args...) do {} while (0)
@@ -1924,7 +1925,7 @@ static void rtl_hw_start_8169(struct net_device *dev)
if ((tp->mac_version == RTL_GIGA_MAC_VER_02) ||
(tp->mac_version == RTL_GIGA_MAC_VER_03)) {
- dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0. "
+ dprintk("Set MAC Reg C+CR Offset 0xE0. "
"Bit-3 and bit-14 MUST be 1\n");
tp->cp_cmd |= (1 << 14);
}
@@ -2289,7 +2290,7 @@ static void rtl8169_reinit_task(struct work_struct *work)
ret = rtl8169_open(dev);
if (unlikely(ret < 0)) {
if (net_ratelimit() && netif_msg_drv(tp)) {
- printk(PFX KERN_ERR "%s: reinit failure (status = %d)."
+ printk(KERN_ERR PFX "%s: reinit failure (status = %d)."
" Rescheduling.\n", dev->name, ret);
}
rtl8169_schedule_work(dev, rtl8169_reinit_task);
@@ -2321,7 +2322,7 @@ static void rtl8169_reset_task(struct work_struct *work)
netif_wake_queue(dev);
} else {
if (net_ratelimit() && netif_msg_intr(tp)) {
- printk(PFX KERN_EMERG "%s: Rx buffers shortage\n",
+ printk(KERN_EMERG PFX "%s: Rx buffers shortage\n",
dev->name);
}
rtl8169_schedule_work(dev, rtl8169_reset_task);
^ permalink raw reply related
* Re: tcp bw in 2.6
From: Ben Greear @ 2007-10-02 16:48 UTC (permalink / raw)
To: lm, Herbert Xu, torvalds, davem, wscott, netdev
In-Reply-To: <20071002154137.GD17418@bitmover.com>
Larry McVoy wrote:
> Interesting data point. My test case is like this:
>
> server
> bind
> listen
> while (newsock = accept...)
> transfer()
>
> client
> connect
> transfer
>
> If the server side is the source of the data, i.e, it's transfer is a
> write loop, then I get the bad behaviour. If I switch them so the data
> flows in the other direction, then it works, I go from about 14K pkt/sec
> to 43K pkt/sec.
>
> Can anyone else reproduce this? I can extract the test case from lmbench
> so it is standalone but I suspect that any test case will do it. I'll
> try with the one that John sent. Yup, s/read/write/ and s/write/read/
> in his two files at the appropriate places and I get exactly the same
> behaviour.
>
> So is this a bug or intentional?
>
I have a more complex configuration & application, but I don't see this
problem in
my testing. Using e1000 nics and modern hardware I can set up a connection
between two machines and run 800+Mbps in both directions, or near line speed
in one direction if the other direction is mostly silent.
I am purposefully setting the socket send/rx buffers, as well has
twiddling with
the tcp and netdev related tunables. If you want, I can email these
tweaks to you.
NICs and busses have a huge impact on performance, so make sure those
are good.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: tcp bw in 2.6
From: Larry McVoy @ 2007-10-02 16:49 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Larry McVoy, Herbert Xu, torvalds, davem, wscott, netdev
In-Reply-To: <20071002094726.154fc619@freepuppy.rosehill>
On Tue, Oct 02, 2007 at 09:47:26AM -0700, Stephen Hemminger wrote:
> On Tue, 2 Oct 2007 09:25:34 -0700
> lm@bitmover.com (Larry McVoy) wrote:
>
> > > If the server side is the source of the data, i.e, it's transfer is a
> > > write loop, then I get the bad behaviour.
> > > ...
> > > So is this a bug or intentional?
> >
> > For whatever it is worth, I believed that we used to get better performance
> > from the same hardware. My guess is that it changed somewhere between
> > 2.6.15-1-k7 and 2.6.18-5-k7.
>
> For the period from 2.6.15 to 2.6.18, the kernel by default enabled TCP
> Appropriate Byte Counting. This caused bad performance on applications that
> did small writes.
It's doing 1MB writes.
Is there a sockopt to turn that off? Or /proc or something?
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
^ permalink raw reply
* Re: tcp bw in 2.6
From: Larry McVoy @ 2007-10-02 16:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Larry McVoy, Herbert Xu, davem, wscott, netdev
In-Reply-To: <alpine.LFD.0.999.0710020930250.3579@woody.linux-foundation.org>
Isn't this something so straightforward that you would have tests for it?
This is the basic FTP server loop, doesn't someone have a big machine with
10gig cards and test that sending/recving data doesn't regress?
> Sounds like a bug to me, modulo the above caveat of making sure that it's
> not some hw/driver/switch kind of difference.
Pretty unlikely given that we've changed the switch, the card works fine
in the other direction, and I'm 95% sure that we used to get better perf
before we switched to a more recent kernel.
I'll try and find some other gig ether cards and try them.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
^ permalink raw reply
* Re: tcp bw in 2.6
From: Stephen Hemminger @ 2007-10-02 16:47 UTC (permalink / raw)
To: Larry McVoy; +Cc: lm, Herbert Xu, torvalds, davem, wscott, netdev
In-Reply-To: <20071002162534.GG17418@bitmover.com>
On Tue, 2 Oct 2007 09:25:34 -0700
lm@bitmover.com (Larry McVoy) wrote:
> > If the server side is the source of the data, i.e, it's transfer is a
> > write loop, then I get the bad behaviour.
> > ...
> > So is this a bug or intentional?
>
> For whatever it is worth, I believed that we used to get better performance
> from the same hardware. My guess is that it changed somewhere between
> 2.6.15-1-k7 and 2.6.18-5-k7.
For the period from 2.6.15 to 2.6.18, the kernel by default enabled TCP
Appropriate Byte Counting. This caused bad performance on applications that
did small writes.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Arnaldo Carvalho de Melo @ 2007-10-02 16:46 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Urs Thuermann, netdev, David Miller, Patrick McHardy,
Thomas Gleixner, YOSHIFUJI Hideaki, Eric W. Biederman,
Oliver Hartkopp, Urs Thuermann
In-Reply-To: <47025EBC.5000301@hartkopp.net>
Em Tue, Oct 02, 2007 at 05:07:40PM +0200, Oliver Hartkopp escreveu:
> Arnaldo Carvalho de Melo wrote:
>> Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
>>
>>> +
>>> +/* To be moved to linux/can/dev.h */
>>>
>>
>> Is this comment still valid? If so can this move happen now? If not I
>> think it would be better to stick a "FIXME: " just before it, no?
>>
>>
>
> Bringing all the current available CAN network device drivers into Kernel
> style qualitiy is a TODO for the time after the PF_CAN core is mainlined.
>
> When more than this single vcan CAN netdev driver is part of the Kernel it
> makes sense to put several things (like the common configuration interface
> and commonly used library funtions for CAN drivers) into linux/can/dev.h.
> And at that time this currently local DEBUG definition should go there
> togehther with the other stuff.
>
> Please think of all the comments, if we created a single dev.h file with a
> single DEBUG definition used by a single vcan.c file ;-)
Don't get to defensive. You know a lot more than me about the code you
worked for that many years. Its just that it looked suspicious for a
casual reviewer. :-)
- Arnaldo
^ permalink raw reply
* Re: tcp bw in 2.6
From: Linus Torvalds @ 2007-10-02 16:34 UTC (permalink / raw)
To: Larry McVoy; +Cc: Herbert Xu, davem, wscott, netdev
In-Reply-To: <20071002154137.GD17418@bitmover.com>
On Tue, 2 Oct 2007, Larry McVoy wrote:
> Interesting data point. My test case is like this:
>
> server
> bind
> listen
> while (newsock = accept...)
> transfer()
>
> client
> connect
> transfer
>
> If the server side is the source of the data, i.e, it's transfer is a
> write loop, then I get the bad behaviour. If I switch them so the data
> flows in the other direction, then it works, I go from about 14K pkt/sec
> to 43K pkt/sec.
Sounds like accept() possibly initializes slightly different socket
parameters than connect() does.
On the other hand, different network cards will simply have different
behaviour (some due to hardware, some due to driver differences), so I
hope you also switched the processes around and/or used identically
configured machines (and the port configuration on switches could matter,
of course, so it's really best to switch the processes around, to make
sure that the *only* difference is whether the socket was set up by
accept() vs connect()).
> So is this a bug or intentional?
Sounds like a bug to me, modulo the above caveat of making sure that it's
not some hw/driver/switch kind of difference.
Linus
^ permalink raw reply
* Re: tcp bw in 2.6
From: Larry McVoy @ 2007-10-02 16:25 UTC (permalink / raw)
To: lm, Herbert Xu, torvalds, davem, wscott, netdev
In-Reply-To: <20071002154137.GD17418@bitmover.com>
> If the server side is the source of the data, i.e, it's transfer is a
> write loop, then I get the bad behaviour.
> ...
> So is this a bug or intentional?
For whatever it is worth, I believed that we used to get better performance
from the same hardware. My guess is that it changed somewhere between
2.6.15-1-k7 and 2.6.18-5-k7.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: Oliver Hartkopp @ 2007-10-02 16:09 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Urs Thuermann, netdev, David Miller, Patrick McHardy,
Thomas Gleixner, YOSHIFUJI Hideaki, Eric W. Biederman,
Oliver Hartkopp, Oliver Hartkopp, Urs Thuermann
In-Reply-To: <20071002143855.GG7881@ghostprotocols.net>
Arnaldo Carvalho de Melo wrote:
> Em Tue, Oct 02, 2007 at 03:10:08PM +0200, Urs Thuermann escreveu:
>
>> +
>> +/**
>> + * struct sockaddr_can - the sockaddr structure for CAN sockets
>> + * @can_family: address family number AF_CAN.
>> + * @can_ifindex: CAN network interface index.
>> + * @can_addr: transport protocol specific address, mostly CAN IDs.
>> + */
>> +struct sockaddr_can {
>> + sa_family_t can_family;
>> + int can_ifindex;
>> + union {
>> + struct { canid_t rx_id, tx_id; } tp16;
>> + struct { canid_t rx_id, tx_id; } tp20;
>> + struct { canid_t rx_id, tx_id; } mcnet;
>> + struct { canid_t rx_id, tx_id; } isotp;
>> + } can_addr;
>>
>
> Again being curious, what is the value of this union of all its members
> have the same definition? Backward source code compatibility?
>
>
Yes. You're right here. It is a prerequisite for a CAN transportprotocol
like the standardized ISO-TP i plan to submit here until december.
Indeed the union should be replaced by something like
struct sockaddr_can {
sa_family_t can_family;
int can_ifindex;
union {
struct { canid_t rx_id, tx_id; } tp;
} can_addr;
};
The union was the idea, if there is any other protocol for CAN that
need's other adressing information. I personally do not know any
protocol. Maybe CANOpen has different addressing requirements here. And
in that case a new protocol could just could add things to the union to
meet it's own needs.
>
> You have been thru many iterations already, sigh, I should have looked
> at this before :-\
>
>
Yeah :-) I thought, you were just done last time.
Btw. Thanks for your review and your good feedback.
Regards,
Oliver
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH V6 0/9] net/bonding: ADD IPoIB support for the bonding driver
From: Moni Shoua @ 2007-10-02 15:49 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Roland Dreier, Jay Vosburgh, OpenFabrics General
In-Reply-To: <10376.1190733869@death>
Jay Vosburgh wrote:
> ACK patches 3 - 9.
>
> Roland, are you comfortable with the IB changes in patches 1 and 2?
>
> Jeff, when Roland acks patches 1 and 2, please apply all 9.
>
> -J
Hi Jeff,
Roland acked the IPoIB patches. If you haven't done so already can you please apply them?
I'm not sure when 2.6.24 is going to open and I'm afraid to miss it.
thanks
^ permalink raw reply
* Re: [RFC PATCH v0.2] net driver: mpc52xx fec
From: Robert Schwebel @ 2007-10-02 15:46 UTC (permalink / raw)
To: Domen Puncer; +Cc: Sascha Hauer, netdev, linuxppc-embedded
In-Reply-To: <20071002143202.GQ32628@nd47.coderock.org>
On Tue, Oct 02, 2007 at 04:32:02PM +0200, Domen Puncer wrote:
> The patch looks ok to me.
Short update: even with the patch, the driver doesn't work on an
rt-preempt enabled kernel, or at least not reliable. It survives normal
traffic and ping -f, but dies when running nmap against the box, with a
set RFIFO_ERROR flag.
More research needs to be done.
Robert
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ permalink raw reply
* Re: tcp bw in 2.6
From: Larry McVoy @ 2007-10-02 15:41 UTC (permalink / raw)
To: lm, Herbert Xu, torvalds, davem, wscott, netdev
In-Reply-To: <20071002150935.GC17418@bitmover.com>
Interesting data point. My test case is like this:
server
bind
listen
while (newsock = accept...)
transfer()
client
connect
transfer
If the server side is the source of the data, i.e, it's transfer is a
write loop, then I get the bad behaviour. If I switch them so the data
flows in the other direction, then it works, I go from about 14K pkt/sec
to 43K pkt/sec.
Can anyone else reproduce this? I can extract the test case from lmbench
so it is standalone but I suspect that any test case will do it. I'll
try with the one that John sent. Yup, s/read/write/ and s/write/read/
in his two files at the appropriate places and I get exactly the same
behaviour.
So is this a bug or intentional?
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
^ permalink raw reply
* Re: Blackfin Ethernet MAC driver compile error
From: Robin Getz @ 2007-10-02 15:36 UTC (permalink / raw)
To: Kalle Pokki; +Cc: linux-kernel, netdev, bryan.wu
In-Reply-To: <a425f86c0710020430o3507eeb2veb104dc936f230dd@mail.gmail.com>
On Tue 2 Oct 2007 07:30, Kalle Pokki pondered:
> The Blackfin Ethernet MAC driver does not compile. It seems the driver is
> missing some pinmux defines.
>
> CC drivers/net/bfin_mac.o
> drivers/net/bfin_mac.c: In function 'setup_pin_mux':
> drivers/net/bfin_mac.c:275: error: 'P_MII0' undeclared (first use in
> this function)
> drivers/net/bfin_mac.c:275: error: (Each undeclared identifier is
> reported only once
> drivers/net/bfin_mac.c:275: error: for each function it appears in.)
Unfortunately, Bryan is out for the week, so he can't update things..
The updates to include/asm-blackfin/mach-bf537/portmux.h seem to have been
missing from Bryan's git tree, and therefore were not pushed to Linus's tree.
Sigh. - Sorry about that.
When Bryan gets back, he will update things, but for now, this might work. (I
don't know if there are any other interdependencies).
--- portmux.h 2007-10-02 11:18:34.000000000 -0400
+++ ./linux-2.6.x/include/asm-blackfin/mach-bf537/portmux.h 2007-08-18
19:37:22.000000000 -0400
@@ -99,11 +99,44 @@
#define P_SPORT0_DRPRI (P_DEFINED | P_IDENT(PORT_PJ8) | P_FUNCT(0))
#define P_SPORT0_TSCLK (P_DEFINED | P_IDENT(PORT_PJ9) | P_FUNCT(0))
#define P_SPORT0_TFS (P_DEFINED | P_IDENT(PORT_PJ10) | P_FUNCT(0))
-#define P_SPORT0_DTPRI (P_DEFINED | P_IDENT(PORT_PJ11) | P_FUNCT(1))
+#define P_SPORT0_DTPRI (P_DEFINED | P_IDENT(PORT_PJ11) | P_FUNCT(0))
#define P_CAN0_RX (P_DEFINED | P_IDENT(PORT_PJ4) | P_FUNCT(1))
#define P_CAN0_TX (P_DEFINED | P_IDENT(PORT_PJ5) | P_FUNCT(1))
#define P_SPI0_SSEL3 (P_DEFINED | P_IDENT(PORT_PJ10) | P_FUNCT(1))
#define P_SPI0_SSEL2 (P_DEFINED | P_IDENT(PORT_PJ11) | P_FUNCT(1))
#define P_SPI0_SSEL7 (P_DEFINED | P_IDENT(PORT_PJ5) | P_FUNCT(2))
-#endif /* _MACH_PORTMUX_H_ */
+#define P_MII0 {\
+ P_MII0_ETxD0, \
+ P_MII0_ETxD1, \
+ P_MII0_ETxD2, \
+ P_MII0_ETxD3, \
+ P_MII0_ETxEN, \
+ P_MII0_TxCLK, \
+ P_MII0_PHYINT, \
+ P_MII0_COL, \
+ P_MII0_ERxD0, \
+ P_MII0_ERxD1, \
+ P_MII0_ERxD2, \
+ P_MII0_ERxD3, \
+ P_MII0_ERxDV, \
+ P_MII0_ERxCLK, \
+ P_MII0_ERxER, \
+ P_MII0_CRS, \
+ P_MDC, \
+ P_MDIO, 0}
+
+
+#define P_RMII0 {\
+ P_MII0_ETxD0, \
+ P_MII0_ETxD1, \
+ P_MII0_ETxEN, \
+ P_MII0_ERxD0, \
+ P_MII0_ERxD1, \
+ P_MII0_ERxER, \
+ P_RMII0_REF_CLK, \
+ P_RMII0_MDINT, \
+ P_RMII0_CRS_DV, \
+ P_MDC, \
+ P_MDIO, 0}
+#endif /* _MACH_PORTMUX_H_ */
> drivers/net/bfin_mac.c:279: error: implicit declaration of function
> 'peripheral_request_list'
> drivers/net/bfin_mac.c:285: error: implicit declaration of function
> 'peripheral_free_list'
Arg.
This was in an arch/blackfin/kernel/bfin_gpio.c update that hasn't seem to
made it either.
In the future - we will make sure driver submissions are done in the correct
order - so the proper infrastructure is in the tree before the driver is
submitted. - Sorry.
Index: arch/blackfin/kernel/bfin_gpio.c
===================================================================
--- arch/blackfin/kernel/bfin_gpio.c (revision 3403)
+++ arch/blackfin/kernel/bfin_gpio.c (revision 3404)
@@ -84,6 +84,7 @@
#include <linux/err.h>
#include <asm/blackfin.h>
#include <asm/gpio.h>
+#include <asm/portmux.h>
#include <linux/irq.h>
#ifdef BF533_FAMILY
@@ -115,8 +116,12 @@
};
#endif
-static unsigned short reserved_map[gpio_bank(MAX_BLACKFIN_GPIOS)];
+static unsigned short reserved_gpio_map[gpio_bank(MAX_BLACKFIN_GPIOS)];
+static unsigned short reserved_peri_map[gpio_bank(MAX_BLACKFIN_GPIOS + 16)];
+char *str_ident = NULL;
+#define RESOURCE_LABEL_SIZE 16
+
#ifdef CONFIG_PM
static unsigned short wakeup_map[gpio_bank(MAX_BLACKFIN_GPIOS)];
static unsigned char wakeup_flags_map[MAX_BLACKFIN_GPIOS];
@@ -143,13 +148,39 @@
return 0;
}
+static void set_label(unsigned short ident, const char *label)
+{
+
+ if (label && str_ident) {
+ strncpy(str_ident + ident * RESOURCE_LABEL_SIZE, label,
+ RESOURCE_LABEL_SIZE);
+ str_ident[ident * RESOURCE_LABEL_SIZE +
+ RESOURCE_LABEL_SIZE - 1] = 0;
+ }
+}
+
+static char *get_label(unsigned short ident)
+{
+ if (!str_ident)
+ return "UNKNOWN";
+
+ return (str_ident[ident * RESOURCE_LABEL_SIZE] ?
+ (str_ident + ident * RESOURCE_LABEL_SIZE) : "UNKNOWN");
+}
+
+static int cmp_label(unsigned short ident, const char *label)
+{
+ if (label && str_ident)
+ return strncmp(str_ident + ident * RESOURCE_LABEL_SIZE,
+ label, strlen(label));
+ else
+ return -EINVAL;
+}
+
#ifdef BF537_FAMILY
static void port_setup(unsigned short gpio, unsigned short usage)
{
if (usage == GPIO_USAGE) {
- if (*port_fer[gpio_bank(gpio)] & gpio_bit(gpio))
- printk(KERN_WARNING "bfin-gpio: Possible Conflict with Peripheral "
- "usage and GPIO %d detected!\n", gpio);
*port_fer[gpio_bank(gpio)] &= ~gpio_bit(gpio);
} else
*port_fer[gpio_bank(gpio)] |= gpio_bit(gpio);
@@ -159,7 +190,57 @@
# define port_setup(...) do { } while (0)
#endif
+#ifdef BF537_FAMILY
+#define PMUX_LUT_RES 0
+#define PMUX_LUT_OFFSET 1
+#define PMUX_LUT_ENTRIES 41
+#define PMUX_LUT_SIZE 2
+
+static unsigned short port_mux_lut[PMUX_LUT_ENTRIES][PMUX_LUT_SIZE] = {
+ {P_PPI0_D13, 11}, {P_PPI0_D14, 11}, {P_PPI0_D15, 11},
+ {P_SPORT1_TFS, 11}, {P_SPORT1_TSCLK, 11}, {P_SPORT1_DTPRI, 11},
+ {P_PPI0_D10, 10}, {P_PPI0_D11, 10}, {P_PPI0_D12, 10},
+ {P_SPORT1_RSCLK, 10}, {P_SPORT1_RFS, 10}, {P_SPORT1_DRPRI, 10},
+ {P_PPI0_D8, 9}, {P_PPI0_D9, 9}, {P_SPORT1_DRSEC, 9},
+ {P_SPORT1_DTSEC, 9}, {P_TMR2, 8}, {P_PPI0_FS3, 8}, {P_TMR3, 7},
+ {P_SPI0_SSEL4, 7}, {P_TMR4, 6}, {P_SPI0_SSEL5, 6}, {P_TMR5, 5},
+ {P_SPI0_SSEL6, 5}, {P_UART1_RX, 4}, {P_UART1_TX, 4}, {P_TMR6, 4},
+ {P_TMR7, 4}, {P_UART0_RX, 3}, {P_UART0_TX, 3}, {P_DMAR0, 3},
+ {P_DMAR1, 3}, {P_SPORT0_DTSEC, 1}, {P_SPORT0_DRSEC, 1},
+ {P_CAN0_RX, 1}, {P_CAN0_TX, 1}, {P_SPI0_SSEL7, 1},
+ {P_SPORT0_TFS, 0}, {P_SPORT0_DTPRI, 0}, {P_SPI0_SSEL2, 0},
+ {P_SPI0_SSEL3, 0}
+};
+
+static void portmux_setup(unsigned short per, unsigned short function)
+{
+ u16 y, muxreg, offset;
+
+ for (y = 0; y < PMUX_LUT_ENTRIES; y++) {
+ if (port_mux_lut[y][PMUX_LUT_RES] == per) {
+
+ /* SET PORTMUX REG */
+
+ offset = port_mux_lut[y][PMUX_LUT_OFFSET];
+ muxreg = bfin_read_PORT_MUX();
+
+ if (offset != 1) {
+ muxreg &= ~(1 << offset);
+ } else {
+ muxreg &= ~(3 << 1);
+ }
+
+ muxreg |= (function << offset);
+ bfin_write_PORT_MUX(muxreg);
+ }
+ }
+}
+
+#else
+# define portmux_setup(...) do { } while (0)
+#endif
+
static void default_gpio(unsigned short gpio)
{
unsigned short bank, bitmask;
@@ -179,22 +260,15 @@
static int __init bfin_gpio_init(void)
{
- int i;
+ str_ident = kzalloc(RESOURCE_LABEL_SIZE * 256, GFP_KERNEL);
+ if (!str_ident)
+ return -ENOMEM;
+
printk(KERN_INFO "Blackfin GPIO Controller\n");
- for (i = 0; i < MAX_BLACKFIN_GPIOS; i += GPIO_BANKSIZE)
- reserved_map[gpio_bank(i)] = 0;
+ return 0;
-#if defined(BF537_FAMILY) && (defined(CONFIG_BFIN_MAC) ||
defined(CONFIG_BFIN_MAC_MODULE))
-# if defined(CONFIG_BFIN_MAC_RMII)
- reserved_map[gpio_bank(PORT_H)] = 0xC373;
-# else
- reserved_map[gpio_bank(PORT_H)] = 0xFFFF;
-# endif
-#endif
-
- return 0;
}
arch_initcall(bfin_gpio_init);
@@ -223,7 +297,7 @@
void set_gpio_ ## name(unsigned short gpio, unsigned short arg) \
{ \
unsigned long flags; \
- BUG_ON(!(reserved_map[gpio_bank(gpio)] & gpio_bit(gpio))); \
+ BUG_ON(!(reserved_gpio_map[gpio_bank(gpio)] & gpio_bit(gpio))); \
local_irq_save(flags); \
if (arg) \
gpio_bankb[gpio_bank(gpio)]->name |= gpio_bit(gpio); \
@@ -243,7 +317,7 @@
#define SET_GPIO_SC(name) \
void set_gpio_ ## name(unsigned short gpio, unsigned short arg) \
{ \
- BUG_ON(!(reserved_map[gpio_bank(gpio)] & gpio_bit(gpio))); \
+ BUG_ON(!(reserved_gpio_map[gpio_bank(gpio)] & gpio_bit(gpio))); \
if (arg) \
gpio_bankb[gpio_bank(gpio)]->name ## _set = gpio_bit(gpio); \
else \
@@ -258,7 +332,7 @@
void set_gpio_data(unsigned short gpio, unsigned short arg)
{
unsigned long flags;
- BUG_ON(!(reserved_map[gpio_bank(gpio)] & gpio_bit(gpio)));
+ BUG_ON(!(reserved_gpio_map[gpio_bank(gpio)] & gpio_bit(gpio)));
local_irq_save(flags);
if (arg)
gpio_bankb[gpio_bank(gpio)]->data_set = gpio_bit(gpio);
@@ -277,7 +351,7 @@
void set_gpio_toggle(unsigned short gpio)
{
unsigned long flags;
- BUG_ON(!(reserved_map[gpio_bank(gpio)] & gpio_bit(gpio)));
+ BUG_ON(!(reserved_gpio_map[gpio_bank(gpio)] & gpio_bit(gpio)));
local_irq_save(flags);
gpio_bankb[gpio_bank(gpio)]->toggle = gpio_bit(gpio);
bfin_read_CHIPID();
@@ -286,7 +360,7 @@
#else
void set_gpio_toggle(unsigned short gpio)
{
- BUG_ON(!(reserved_map[gpio_bank(gpio)] & gpio_bit(gpio)));
+ BUG_ON(!(reserved_gpio_map[gpio_bank(gpio)] & gpio_bit(gpio)));
gpio_bankb[gpio_bank(gpio)]->toggle = gpio_bit(gpio);
}
#endif
@@ -350,7 +424,7 @@
{
unsigned long flags;
unsigned short ret;
- BUG_ON(!(reserved_map[gpio_bank(gpio)] & gpio_bit(gpio)));
+ BUG_ON(!(reserved_gpio_map[gpio_bank(gpio)] & gpio_bit(gpio)));
local_irq_save(flags);
ret = 0x01 & (gpio_bankb[gpio_bank(gpio)]->data >> gpio_sub_n(gpio));
bfin_read_CHIPID();
@@ -494,13 +568,14 @@
gpio_bank_saved[bank].dir = gpio_bankb[bank]->dir;
gpio_bank_saved[bank].edge = gpio_bankb[bank]->edge;
gpio_bank_saved[bank].both = gpio_bankb[bank]->both;
- gpio_bank_saved[bank].reserved = reserved_map[bank];
+ gpio_bank_saved[bank].reserved =
+ reserved_gpio_map[bank];
gpio = i;
while (mask) {
if (mask & 1) {
- reserved_map[gpio_bank(gpio)] |=
+ reserved_gpio_map[gpio_bank(gpio)] |=
gpio_bit(gpio);
bfin_gpio_wakeup_type(gpio,
wakeup_flags_map[gpio]);
@@ -540,7 +615,8 @@
gpio_bankb[bank]->edge = gpio_bank_saved[bank].edge;
gpio_bankb[bank]->both = gpio_bank_saved[bank].both;
- reserved_map[bank] = gpio_bank_saved[bank].reserved;
+ reserved_gpio_map[bank] =
+ gpio_bank_saved[bank].reserved;
}
@@ -550,6 +626,140 @@
#endif
+
+
+
+int peripheral_request(unsigned short per, const char *label)
+{
+ unsigned long flags;
+ unsigned short ident = P_IDENT(per);
+
+ /*
+ * Don't cares are pins with only one dedicated function
+ */
+
+ if (per & P_DONTCARE)
+ return 0;
+
+ if (!(per & P_DEFINED))
+ return -ENODEV;
+
+ if (check_gpio(ident) < 0)
+ return -EINVAL;
+
+ local_irq_save(flags);
+
+ if (unlikely(reserved_gpio_map[gpio_bank(ident)] & gpio_bit(ident))) {
+ printk(KERN_ERR
+ "%s: Peripheral %d is already reserved as GPIO by %s !\n",
+ __FUNCTION__, ident, get_label(ident));
+ dump_stack();
+ local_irq_restore(flags);
+ return -EBUSY;
+ }
+
+ if (unlikely(reserved_peri_map[gpio_bank(ident)] & gpio_bit(ident))) {
+
+ /*
+ * Pin functions like AMC address strobes my
+ * be requested and used by several drivers
+ */
+
+ if (!(per & P_MAYSHARE)) {
+
+ /*
+ * Allow that the identical pin function can
+ * be requested from the same driver twice
+ */
+
+ if (cmp_label(ident, label) == 0)
+ goto anyway;
+
+ printk(KERN_ERR
+ "%s: Peripheral %d function %d is already"
+ "reserved by %s !\n",
+ __FUNCTION__, ident, P_FUNCT2MUX(per),
+ get_label(ident));
+ dump_stack();
+ local_irq_restore(flags);
+ return -EBUSY;
+ }
+
+ }
+
+anyway:
+
+
+ portmux_setup(per, P_FUNCT2MUX(per));
+
+ port_setup(ident, PERIPHERAL_USAGE);
+
+ reserved_peri_map[gpio_bank(ident)] |= gpio_bit(ident);
+ local_irq_restore(flags);
+ set_label(ident, label);
+
+ return 0;
+}
+EXPORT_SYMBOL(peripheral_request);
+
+int peripheral_request_list(unsigned short per[], const char *label)
+{
+ u16 cnt;
+ int ret;
+
+ for (cnt = 0; per[cnt] != 0; cnt++) {
+ ret = peripheral_request(per[cnt], label);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(peripheral_request_list);
+
+void peripheral_free(unsigned short per)
+{
+ unsigned long flags;
+ unsigned short ident = P_IDENT(per);
+
+ if (per & P_DONTCARE)
+ return;
+
+ if (!(per & P_DEFINED))
+ return;
+
+ if (check_gpio(ident) < 0)
+ return;
+
+ local_irq_save(flags);
+
+ if (unlikely(!(reserved_peri_map[gpio_bank(ident)]
+ & gpio_bit(ident)))) {
+ local_irq_restore(flags);
+ return;
+ }
+
+ if (!(per & P_MAYSHARE)) {
+ port_setup(ident, GPIO_USAGE);
+ }
+
+ reserved_peri_map[gpio_bank(ident)] &= ~gpio_bit(ident);
+
+ local_irq_restore(flags);
+}
+EXPORT_SYMBOL(peripheral_free);
+
+void peripheral_free_list(unsigned short per[])
+{
+ u16 cnt;
+
+ for (cnt = 0; per[cnt] != 0; cnt++) {
+ peripheral_free(per[cnt]);
+ }
+
+}
+EXPORT_SYMBOL(peripheral_free_list);
+
/***********************************************************
*
* FUNCTIONS: Blackfin GPIO Driver
@@ -574,13 +784,13 @@
local_irq_save(flags);
- if (unlikely(reserved_map[gpio_bank(gpio)] & gpio_bit(gpio))) {
+ if (unlikely(reserved_gpio_map[gpio_bank(gpio)] & gpio_bit(gpio))) {
printk(KERN_ERR "bfin-gpio: GPIO %d is already reserved!\n", gpio);
dump_stack();
local_irq_restore(flags);
return -EBUSY;
}
- reserved_map[gpio_bank(gpio)] |= gpio_bit(gpio);
+ reserved_gpio_map[gpio_bank(gpio)] |= gpio_bit(gpio);
local_irq_restore(flags);
@@ -599,7 +809,7 @@
local_irq_save(flags);
- if (unlikely(!(reserved_map[gpio_bank(gpio)] & gpio_bit(gpio)))) {
+ if (unlikely(!(reserved_gpio_map[gpio_bank(gpio)] & gpio_bit(gpio)))) {
printk(KERN_ERR "bfin-gpio: GPIO %d wasn't reserved!\n", gpio);
dump_stack();
local_irq_restore(flags);
@@ -608,7 +818,7 @@
default_gpio(gpio);
- reserved_map[gpio_bank(gpio)] &= ~gpio_bit(gpio);
+ reserved_gpio_map[gpio_bank(gpio)] &= ~gpio_bit(gpio);
local_irq_restore(flags);
}
@@ -618,7 +828,7 @@
{
unsigned long flags;
- BUG_ON(!(reserved_map[gpio_bank(gpio)] & gpio_bit(gpio)));
+ BUG_ON(!(reserved_gpio_map[gpio_bank(gpio)] & gpio_bit(gpio)));
local_irq_save(flags);
gpio_bankb[gpio_bank(gpio)]->dir &= ~gpio_bit(gpio);
@@ -631,7 +841,7 @@
{
unsigned long flags;
- BUG_ON(!(reserved_map[gpio_bank(gpio)] & gpio_bit(gpio)));
+ BUG_ON(!(reserved_gpio_map[gpio_bank(gpio)] & gpio_bit(gpio)));
local_irq_save(flags);
gpio_bankb[gpio_bank(gpio)]->inen &= ~gpio_bit(gpio);
^ permalink raw reply
* Re: [PATCH] Fallback to ipv4 if we try to add join IPv4 multicast group via ipv4-mapped address.
From: David Stevens @ 2007-10-02 15:35 UTC (permalink / raw)
To: Dmitry Baryshkov; +Cc: linux-kernel, netdev, netdev-owner
In-Reply-To: <1191319182.28331.6.camel@doriath.ww600.siemens.net>
Dmitry,
Good catch; a couple comments:
> struct ipv6_pinfo *np = inet6_sk(sk);
> int err;
> + int addr_type = ipv6_addr_type(addr);
> +
> + if (addr_type == IPV6_ADDR_MAPPED) {
> + __be32 v4addr = addr->s6_addr32[3];
> + struct ip_mreqn mreq;
> + mreq.imr_multiaddr.s_addr = v4addr;
> + mreq.imr_address.s_addr = INADDR_ANY;
> + mreq.imr_ifindex = ifindex;
> +
> + return ip_mc_join_group(sk, &mreq);
> + }
ipv6_addr_type() returns a bitmask, so you should use:
if (addr_type & IPV6_ADDR_MAPPED) {
Also, you should have a blank line after the "mreq" declaration.
Ditto for both in ipv6_mc_sock_drop().
I don't expect the multicast source filtering interface will
behave well for mapped addresses, either. The mapped multicast
address won't appear to be a multicast address (and return
error there), and all the source filters would have to be
v4mapped addresses and modify the v4 source filters for this
to do as you expect. So, there's more to it (and it may be a
bit messy) to support mapped multicast addresses fully. I'll
think about that part some more.
+-DLS
^ permalink raw reply
* Re: [PATCH] rtnl: Simplify ASSERT_RTNL
From: Patrick McHardy @ 2007-10-02 15:29 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, oliver, Eric W. Biederman, linux-usb-devel, davem
In-Reply-To: <20071002092819.GA29824@gondor.apana.org.au>
On Tue, 2 Oct 2007, Herbert Xu wrote:
> On Sun, Sep 30, 2007 at 05:47:30PM +0200, Patrick McHardy wrote:
>>
> I'm a bit uncomfortable with having a function (change_flags)
> that's sometimes in a sleepable context and sometimes running
> with BH disabled.
>
> So how about splitting up the unicast/multicast entry points
> as follows?
>
> [NET]: Restore multicast-only __dev_mc_upload
>
> As it is dev_set_rx_mode needs to cope with being called with
> or without the RTNL. This is rather confusing when it comes
> to understanding what locks are being held at a particular
> point.
>
> Since the only path that calls it without the RTNL is in the
> multicast code, we could avoid the confusion by splitting that
> out.
>
> This patch restores the old __dev_mc_upload as a multicast-only
> variant of dev_set_rx_mode. It also gets rid of the now-unused
> __dev_set_rx_mod and makes dev_set_rx_mode static since it's
> only used in net/core/dev.c.
>
> As a side-effect this fixes the warning triggered by the
> RTNL_ASSERT in __dev_set_promiscuity.
I think this doesn't completely fix it, when dev_unicast_add is
interrupted by dev_mc_add before the unicast changes are performed,
they will get committed in the dev_mc_add context, so we might still
call change_flags with BH disabled. Taking the TX lock around the
dev->uc_count and dev->uc_promisc checks and changes in __dev_set_rx_mode
should fix this.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* [PATCH 2.6.23-rc8-mm2] Fix a compile problem in macb.c
From: Haavard Skinnemoen @ 2007-10-02 15:23 UTC (permalink / raw)
To: David Miller
Cc: Jeff Garzik, netdev, Andrew Morton, Hans-Jürgen Koch,
Haavard Skinnemoen
From: Hans-Jürgen Koch <hjk@linutronix.de>
Compiling macb.c fails because the type of parameter 2 of macb_poll()
was changed from int* to int. Furthermore, a local variable was removed
but was still used inside the function. This patch fixes it.
Signed-off-by: Hans J. Koch <hjk@linutronix.de>
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
---
drivers/net/macb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index c28a0a4..047ea7b 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -492,7 +492,7 @@ static int macb_poll(struct napi_struct *napi, int budget)
}
dev_dbg(&bp->pdev->dev, "poll: status = %08lx, budget = %d\n",
- (unsigned long)status, *budget);
+ (unsigned long)status, budget);
if (!(status & MACB_BIT(REC))) {
dev_warn(&bp->pdev->dev,
@@ -503,7 +503,7 @@ static int macb_poll(struct napi_struct *napi, int budget)
}
work_done = macb_rx(bp, budget);
- if (work_done < orig_budget)
+ if (work_done < budget)
netif_rx_complete(dev, napi);
/*
--
1.5.3.1
^ permalink raw reply related
* Re: tcp bw in 2.6
From: Larry McVoy @ 2007-10-02 15:09 UTC (permalink / raw)
To: Herbert Xu; +Cc: Larry McVoy, torvalds, davem, wscott, netdev
In-Reply-To: <E1IcfN0-0007tt-00@gondolin.me.apana.org.au>
On Tue, Oct 02, 2007 at 06:52:54PM +0800, Herbert Xu wrote:
> > One of my clients also has gigabit so I played around with just that
> > one and it (itanium running hpux w/ broadcom gigabit) can push the load
> > as well. One weird thing is that it is dependent on the direction the
> > data is flowing. If the hp is sending then I get 46MB/sec, if linux is
> > sending then I get 18MB/sec. Weird. Linux is debian, running
>
> First of all check the CPU load on both sides to see if either
> of them is saturating. If the CPU's fine then look at the tcpdump
> output to see if both receivers are using the same window settings.
tcpdump is a good idea, take a look at this. The window starts out
at 46 and never opens up in my test case, but in the rsh case it
starts out the same but does open up. Ideas?
08:08:06.033305 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: S 2756874880:2756874880(0) win 32768 <mss 1460,wscale 0,nop>
08:08:06.033335 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: S 3360532803:3360532803(0) ack 2756874881 win 5840 <mss 1460,nop,wscale 7>
08:08:06.047924 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 1 win 32768
08:08:06.048218 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 1:2921(2920) ack 1 win 46
08:08:06.048426 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 1461 win 32768
08:08:06.048446 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 2921:5841(2920) ack 1 win 46
08:08:06.048673 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 4381 win 32768
08:08:06.048684 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 5841:10221(4380) ack 1 win 46
08:08:06.049047 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 8761 win 32768
08:08:06.049057 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 10221:16061(5840) ack 1 win 46
08:08:06.049422 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 14601 win 32768
08:08:06.049429 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 16061:18981(2920) ack 1 win 46
08:08:06.049462 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 18981:20441(1460) ack 1 win 46
08:08:06.049484 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 20441:23361(2920) ack 1 win 46
08:08:06.049924 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 21901 win 32768
08:08:06.049943 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 23361:32121(8760) ack 1 win 46
08:08:06.050549 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 30661 win 32768
08:08:06.050559 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 32121:39421(7300) ack 1 win 46
08:08:06.050592 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 39421:40881(1460) ack 1 win 46
08:08:06.050614 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 40881:42341(1460) ack 1 win 46
08:08:06.051170 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 40881 win 32768
08:08:06.051188 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 42341:54021(11680) ack 1 win 46
08:08:06.051923 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 52561 win 32768
08:08:06.051932 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 54021:58401(4380) ack 1 win 46
08:08:06.051942 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 58401:67161(8760) ack 1 win 46
08:08:06.052671 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 65701 win 32768
08:08:06.052680 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 67161:74461(7300) ack 1 win 46
08:08:06.052719 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 74461:77381(2920) ack 1 win 46
08:08:06.052752 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 77381:81761(4380) ack 1 win 46
08:08:06.053549 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 80301 win 32768
08:08:06.053566 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 81761:97821(16060) ack 1 win 46
08:08:06.054423 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 96361 win 32768
08:08:06.054433 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 97821:113881(16060) ack 1 win 46
08:08:06.054476 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 113881:115341(1460) ack 1 win 46
08:08:06.055422 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 113881 win 32768
08:08:06.055438 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 115341:131401(16060) ack 1 win 46
08:08:06.056421 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 131401 win 32768
08:08:06.056432 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 131401:147461(16060) ack 1 win 46
08:08:06.117889 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 147461 win 32768
08:08:06.117897 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 147461:163521(16060) ack 1 win 46
08:08:06.118392 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 148921 win 32768
08:08:06.118405 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 163521:173741(10220) ack 1 win 46
08:08:06.118640 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 151841 win 32768
08:08:06.118768 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 156221 win 32768
08:08:06.118775 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 173741:179581(5840) ack 1 win 46
08:08:06.118783 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 162061 win 32768
08:08:06.118793 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 179581:191261(11680) ack 1 win 46
08:08:06.119388 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 169361 win 32768
08:08:06.119644 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 178121 win 32768
08:08:06.119654 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 191261:195641(4380) ack 1 win 46
08:08:06.119665 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 195641:210241(14600) ack 1 win 46
08:08:06.120265 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 188341 win 32768
08:08:06.120274 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 210241:211701(1460) ack 1 win 46
08:08:06.121137 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 200021 win 32768
08:08:06.121148 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 211701:227761(16060) ack 1 win 46
08:08:06.121763 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 213161 win 32768
08:08:06.121772 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 227761:243821(16060) ack 1 win 46
08:08:06.122385 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 227761 win 32768
08:08:06.122396 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 243821:259881(16060) ack 1 win 46
08:08:06.123260 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 243821 win 32768
08:08:06.123269 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 259881:275941(16060) ack 1 win 46
08:08:06.124008 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 259881 win 32768
08:08:06.124021 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 275941:292001(16060) ack 1 win 46
08:08:06.124884 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 275941 win 32768
08:08:06.124894 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 292001:308061(16060) ack 1 win 46
08:08:06.125637 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 292001 win 32768
08:08:06.125647 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 308061:324121(16060) ack 1 win 46
08:08:06.126512 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 308061 win 32768
08:08:06.126522 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 324121:340181(16060) ack 1 win 46
08:08:06.127383 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 324121 win 32768
08:08:06.127393 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 340181:356241(16060) ack 1 win 46
08:08:06.128135 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 340181 win 32768
08:08:06.128146 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 356241:372301(16060) ack 1 win 46
08:08:06.129010 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 356241 win 32768
08:08:06.129020 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 372301:388361(16060) ack 1 win 46
08:08:06.129761 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 372301 win 32768
08:08:06.129770 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 388361:404421(16060) ack 1 win 46
08:08:06.130636 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 388361 win 32768
08:08:06.130645 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 404421:420481(16060) ack 1 win 46
08:08:06.131510 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 404421 win 32768
08:08:06.131521 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 420481:436541(16060) ack 1 win 46
08:08:06.132130 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 420481 win 32768
08:08:06.132140 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 436541:452601(16060) ack 1 win 46
08:08:06.132886 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 436541 win 32768
08:08:06.132895 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 452601:468661(16060) ack 1 win 46
08:08:06.133754 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 452601 win 32768
08:08:06.133765 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 468661:484721(16060) ack 1 win 46
08:08:06.134630 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 468661 win 32768
08:08:06.134640 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 484721:500781(16060) ack 1 win 46
08:08:06.135384 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 484721 win 32768
08:08:06.135395 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 500781:516841(16060) ack 1 win 46
08:08:06.136258 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 500781 win 32768
08:08:06.136272 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 516841:532901(16060) ack 1 win 46
08:08:06.137006 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 516841 win 32768
08:08:06.137016 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 532901:548961(16060) ack 1 win 46
08:08:06.137880 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 532901 win 32768
08:08:06.137891 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 548961:565021(16060) ack 1 win 46
08:08:06.138756 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 548961 win 32768
08:08:06.138768 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 565021:581081(16060) ack 1 win 46
08:08:06.139505 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 565021 win 32768
08:08:18.842450 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 3613368208 win 32768
08:08:18.844056 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 16061:32121(16060) ack 0 win 46
08:08:18.843057 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 16061 win 32768
08:08:18.843069 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 32121:48181(16060) ack 0 win 46
08:08:18.843932 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 32121 win 32768
08:08:18.843942 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 48181:64241(16060) ack 0 win 46
08:08:18.844681 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 48181 win 32768
08:08:18.844690 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 64241:80301(16060) ack 0 win 46
08:08:18.845556 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 64241 win 32768
08:08:18.845566 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 80301:96361(16060) ack 0 win 46
08:08:18.846304 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 80301 win 32768
08:08:18.846313 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 96361:112421(16060) ack 0 win 46
08:08:18.847178 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 96361 win 32768
08:08:18.847187 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 112421:128481(16060) ack 0 win 46
08:08:18.848053 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 112421 win 32768
08:08:18.848063 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 128481:144541(16060) ack 0 win 46
08:08:18.848941 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 128481 win 32768
08:08:18.848952 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 144541:160601(16060) ack 0 win 46
08:08:18.849553 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 144541 win 32768
08:08:18.849561 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 160601:176661(16060) ack 0 win 46
08:08:18.850306 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 160601 win 32768
08:08:18.850316 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 176661:192721(16060) ack 0 win 46
08:08:18.851174 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 176661 win 32768
08:08:18.851182 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 192721:208781(16060) ack 0 win 46
08:08:18.852055 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 192721 win 32768
08:08:18.852064 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 208781:224841(16060) ack 0 win 46
08:08:18.852802 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 208781 win 32768
08:08:18.852810 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 224841:240901(16060) ack 0 win 46
08:08:18.853677 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 224841 win 32768
08:08:18.853687 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 240901:256961(16060) ack 0 win 46
08:08:18.854427 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 240901 win 32768
08:08:18.854436 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 256961:273021(16060) ack 0 win 46
08:08:18.855302 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 256961 win 32768
08:08:18.855311 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 273021:289081(16060) ack 0 win 46
08:08:18.856048 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 273021 win 32768
08:08:18.856058 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 289081:305141(16060) ack 0 win 46
08:08:18.856925 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 289081 win 32768
08:08:18.856934 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 305141:321201(16060) ack 0 win 46
08:08:18.857800 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 305141 win 32768
08:08:18.857809 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 321201:337261(16060) ack 0 win 46
08:08:18.858548 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 321201 win 32768
08:08:18.858556 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 337261:353321(16060) ack 0 win 46
08:08:18.859424 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 337261 win 32768
08:08:18.859432 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 353321:369381(16060) ack 0 win 46
08:08:18.860045 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 353321 win 32768
08:08:18.860054 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 369381:385441(16060) ack 0 win 46
08:08:18.860799 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 369381 win 32768
08:08:18.860807 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 385441:401501(16060) ack 0 win 46
08:08:18.861673 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 385441 win 32768
08:08:18.861683 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 401501:417561(16060) ack 0 win 46
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Oliver Hartkopp @ 2007-10-02 15:07 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Urs Thuermann, netdev, David Miller, Patrick McHardy,
Thomas Gleixner, YOSHIFUJI Hideaki, Eric W. Biederman,
Oliver Hartkopp, Oliver Hartkopp, Urs Thuermann
In-Reply-To: <20071002142016.GE7881@ghostprotocols.net>
Arnaldo Carvalho de Melo wrote:
> Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
>
>
>> +
>> +/* To be moved to linux/can/dev.h */
>>
>
> Is this comment still valid? If so can this move happen now? If not I
> think it would be better to stick a "FIXME: " just before it, no?
>
>
Bringing all the current available CAN network device drivers into
Kernel style qualitiy is a TODO for the time after the PF_CAN core is
mainlined.
When more than this single vcan CAN netdev driver is part of the Kernel
it makes sense to put several things (like the common configuration
interface and commonly used library funtions for CAN drivers) into
linux/can/dev.h. And at that time this currently local DEBUG definition
should go there togehther with the other stuff.
Please think of all the comments, if we created a single dev.h file with
a single DEBUG definition used by a single vcan.c file ;-)
Oliver
^ permalink raw reply
* Re: tcp bw in 2.6
From: John Heffner @ 2007-10-02 15:06 UTC (permalink / raw)
To: lm, Linus Torvalds, davem, wscott, netdev
In-Reply-To: <20071002022059.GE7037@bitmover.com>
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
Larry McVoy wrote:
> A short summary is "can someone please post a test program that sources
> and sinks data at the wire speed?" because apparently I'm too old and
> clueless to write such a thing.
Here's a simple reference tcp source/sink that's I've used for years.
For example, on a couple gigabit machines:
$ ./tcpsend -t10 dew
Sent 1240415312 bytes in 10.033101 seconds
Throughput: 123632294 B/s
-John
[-- Attachment #2: discard.c --]
[-- Type: text/plain, Size: 2332 bytes --]
/*
* discard.c
* A simple discard server.
*
* Copyright 2003 John Heffner.
*/
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/poll.h>
#include <sys/wait.h>
#include <sys/time.h>
#include <sys/param.h>
#include <netinet/in.h>
#if 0
#define RATELIMIT
#define RATE 100000 /* bytes/sec */
#define WAIT_TIME (1000000/HZ-1)
#define READ_SIZE (RATE/HZ)
#else
#define READ_SIZE (1024*1024)
#endif
void child_handler(int sig)
{
int status;
wait(&status);
}
int main(int argc, char *argv[])
{
int port = 9000;
int lfd;
struct sockaddr_in laddr;
int newfd;
struct sockaddr_in newaddr;
int pid;
socklen_t len;
if (argc > 2) {
fprintf(stderr, "usage: discard [port]\n");
exit(1);
}
if (argc == 2) {
if (sscanf(argv[1], "%d", &port) != 1 || port < 0 || port > 65535) {
fprintf(stderr, "discard: error: not a port number\n");
exit(1);
}
}
if (signal(SIGCHLD, child_handler) == SIG_ERR) {
perror("signal");
exit(1);
}
memset(&laddr, 0, sizeof (laddr));
laddr.sin_family = AF_INET;
laddr.sin_port = htons(port);
laddr.sin_addr.s_addr = INADDR_ANY;
if ((lfd = socket(PF_INET, SOCK_STREAM, 0)) < 0) {
perror("socket");
exit(1);
}
if (bind(lfd, (struct sockaddr *)&laddr, sizeof (laddr)) != 0) {
perror("bind");
exit(1);
}
if (listen(lfd, 5) != 0) {
perror("listen");
exit(1);
}
for (;;) {
if ((newfd = accept(lfd, (struct sockaddr *)&newaddr, &len)) < 0) {
if (errno == EINTR)
continue;
perror("accept");
exit(1);
}
if ((pid = fork()) < 0) {
perror("fork");
exit(1);
} else if (pid == 0) {
int n;
char buf[READ_SIZE];
int64_t data_rcvd = 0;
struct timeval stime, etime;
float time;
gettimeofday(&stime, NULL);
while ((n = read(newfd, buf, READ_SIZE)) > 0) {
data_rcvd += n;
#ifdef RATELIMIT
usleep(WAIT_TIME);
#endif
}
gettimeofday(&etime, NULL);
close(newfd);
time = (float)(1000000*(etime.tv_sec - stime.tv_sec) + etime.tv_usec - stime.tv_usec) / 1000000.0;
printf("Received %lld bytes in %f seconds\n", (long long)data_rcvd, time);
printf("Throughput: %d B/s\n", (int)((float)data_rcvd / time));
exit(0);
}
close(newfd);
}
return 1;
}
[-- Attachment #3: tcpsend.c --]
[-- Type: text/plain, Size: 6268 bytes --]
/*
* tcpsend.c
* Send pseudo-random data through a TCP connection.
*
* Copyright 2003 John Heffner.
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <netdb.h>
#include <signal.h>
#include <errno.h>
#include <fcntl.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <sys/stat.h>
#ifdef __linux__
#include <sys/sendfile.h>
#endif
#define SNDSIZE (1024 * 10)
#define BUFSIZE (1024 * 1024)
#define max(a,b) (a > b ? a : b)
#define min(a,b) (a < b ? a : b)
int time_done = 0;
int interrupt_done = 0;
struct timeval starttime;
void int_handler(int sig)
{
interrupt_done = 1;
}
void alarm_handler(int sig)
{
time_done = 1;
}
static void usage_error(int err) {
fprintf(stderr, "usage: tcpsend [-z] [-b max_bytes] [-t max_time] hostname [port]\n");
exit(err);
}
static void cleanup_exit(int fd, char *filename, int status)
{
if (fd > 0)
close(fd);
if (filename)
unlink(filename);
exit(status);
}
int main(int argc, char *argv[])
{
char *hostname = "localhost";
int port = 9000;
int max_time = -1;
int max_bytes = -1;
int zerocopy = 0;
int sockfd;
struct sockaddr_in addr;
struct hostent *hent;
struct sigaction act;
int i;
int arg_state;
char *tmp;
int add;
char *buf;
int64_t data_sent;
int n;
off_t start;
int amt;
struct timeval etime;
float time;
int err;
char *namebuf = NULL;
int fd = -1;
/* Read in args */
if (argc == 2 && strcmp(argv[1], "-h") == 0)
usage_error(0);
for (arg_state = 0, i = 1; i < argc; i++) {
if (argv[i][0] == '-') {
if (arg_state != 0)
usage_error(1);
if (strlen(argv[i]) < 2)
usage_error(1);
add = 0;
if (argv[i][1] == 'z') {
zerocopy = 1;
} else if (argv[i][1] == 'b' ||
argv[i][1] == 't') {
if (strlen(argv[i]) > 2) {
tmp = &(argv[i][2]);
} else {
add = 1;
if (i + 1 >= argc)
usage_error(1);
tmp = argv[i + 1];
}
if (argv[i][1] == 'b') {
if (sscanf(tmp, "%d", &max_bytes) != 1 ||
max_bytes < 0)
usage_error(1);
} else {
if (sscanf(tmp, "%d", &max_time) != 1 ||
max_time < 0)
usage_error(1);
}
} else {
usage_error(1);
}
i += add;
} else {
switch (arg_state) {
case 0:
arg_state = 1;
hostname = argv[i];
break;
case 1:
arg_state = 2;
if (sscanf(argv[i], "%d", &port) != 1 ||
port < 0 || port > 65535)
usage_error(1);
break;
default:
usage_error(1);
}
}
}
if (arg_state < 1)
usage_error(1);
#ifndef __linux__
if (zerocopy) {
fprintf(stderr, "Zero-copy is only supported under Linux.\n");
exit(1);
}
#endif
/* Set up addr struct from hostname and port */
if ((hent = gethostbyname(hostname)) == NULL) {
fprintf(stderr, "tcpsend: gethostbyname error\n");
exit(1);
}
memset(&addr, 0, sizeof (addr));
addr.sin_family = AF_INET;
memcpy(&addr.sin_addr, hent->h_addr_list[0], 4);
addr.sin_port = htons(port);
/* Create buffer and fill with random data */
if (gettimeofday(&starttime, NULL) < 0) {
perror("gettimeofday");
exit(1);
}
srand((unsigned int)(starttime.tv_usec + 1000000 * starttime.tv_sec));
if ((buf = (char *)malloc(BUFSIZE)) == NULL) {
fprintf(stderr, "malloc failed\n");
exit(1);
}
for (i = 0; i < BUFSIZE; i += sizeof (int)) {
*(int *)&buf[i] = rand();
}
if (zerocopy) {
if ((namebuf = malloc(64)) == NULL) {
fprintf(stderr, "malloc failed\n");
exit(1);
}
sprintf(namebuf, "/tmp/tcpsend%d", getpid());
if ((fd = open(namebuf, O_RDWR | O_CREAT, 0600)) < 0) {
perror("open");
exit(1);
}
for (amt = BUFSIZE; amt > 0; ) {
if ((n = write(fd, buf, amt)) < 0) {
perror("write");
cleanup_exit(fd, namebuf, 1);
}
amt -= n;
}
}
/* Open connection */
if ((sockfd = socket(PF_INET, SOCK_STREAM, 0)) < 0) {
perror("socket");
cleanup_exit(fd, namebuf, 1);
}
if (connect(sockfd, (struct sockaddr *)&addr, sizeof (addr)) != 0) {
perror("connect");
cleanup_exit(fd, namebuf, 1);
}
/* Set up signal handlers */
if (max_time >= 0) {
if (sigaction(SIGALRM, NULL, &act) != 0) {
perror("sigaction: SIGALRM");
cleanup_exit(fd, namebuf, 1);
}
act.sa_handler = alarm_handler;
act.sa_flags = 0;
if (sigaction(SIGALRM, &act, NULL) != 0) {
perror("sigaction: SIGALRM");
cleanup_exit(fd, namebuf, 1);
}
alarm(max_time);
}
if (sigaction(SIGINT, NULL, &act) != 0) {
perror("sigaction: SIGINT");
cleanup_exit(fd, namebuf, 1);
}
act.sa_handler = int_handler;
act.sa_flags = 0;
if (sigaction(SIGINT, &act, NULL) != 0) {
perror("sigaction: SIGINT");
cleanup_exit(fd, namebuf, 1);
}
/* Send random data until we hit a max */
data_sent = 0;
while ((max_bytes < 0 ? 1 : data_sent < max_bytes) &&
!time_done && !interrupt_done) {
start = rand() / (RAND_MAX / (BUFSIZE - SNDSIZE) + 1);
if (max_bytes < 0)
amt = SNDSIZE;
else
amt = min(SNDSIZE, max_bytes - data_sent);
if (zerocopy) {
#ifdef __linux__
if ((n = sendfile(sockfd, fd, &start, amt)) < 0 && errno != EINTR) {
perror("sendfile");
cleanup_exit(fd, namebuf, 1);
} else if (n == 0) {
fprintf(stderr, "tcpsend: socket unexpectedly closed\n");
cleanup_exit(fd, namebuf, 1);
}
#endif
} else {
if ((n = write(sockfd, &buf[start], amt)) < 0 && errno != EINTR) {
perror("write");
cleanup_exit(fd, namebuf, 1);
} else if (n == 0) {
fprintf(stderr, "tcpsend: socket unexpectedly closed\n");
cleanup_exit(fd, namebuf, 1);
}
}
data_sent += n;
}
/* Close the socket and wait for the remote host to close */
if (shutdown(sockfd, SHUT_WR) != 0) {
perror("shutdown");
cleanup_exit(fd, namebuf, 1);
}
err = read(sockfd, buf, 1);
if (err < 0) {
perror("read");
cleanup_exit(fd, namebuf, 1);
} else if (err > 0) {
fprintf(stderr, "warning: data read on socket\n");
}
gettimeofday(&etime, NULL);
time = (float)(1000000*(etime.tv_sec - starttime.tv_sec) +
etime.tv_usec - starttime.tv_usec) / 1000000.0;
printf("Sent %lld bytes in %f seconds\n", (long long)data_sent, time);
printf("Throughput: %d B/s\n", (int)((float)data_sent / time));
cleanup_exit(fd, namebuf, 0);
return 0;
}
[-- Attachment #4: Makefile --]
[-- Type: text/plain, Size: 75 bytes --]
CFLAGS = -g -O2 -Wall
all: tcpsend discard
clean:
rm -f tcpsend discard
^ 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