* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Oliver Hartkopp @ 2007-09-28 18:33 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Urs Thuermann, netdev, David Miller, Patrick McHardy,
Thomas Gleixner, Oliver Hartkopp, Urs Thuermann, Daniel Lezcano
In-Reply-To: <m1hcled960.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> Oliver Hartkopp <oliver@hartkopp.net> writes:
>
>> The CAN protocol family is some kind of a closed ecosystem with a
>> complete different addressing scheme that uses the bare networking
>> functionality of the Linux Kernel as well as DECNET or ARCNET. You would
>> never been able to run the IP-stack on a CAN netdev (ARPHDR_CAN,
>> ETH_P_CAN) due to several technical differences in addressing, etc.
>>
>
> However when register_netdev is the netdev_notifier chain is called
> with NETDEV_REGISTER
>
> So then we enter code paths such as "net/ipv4/inetdev_event()" and
> process the network device. There is some small amount of treatment
> given to devices that have IFF_LOOPBACK set.
>
Yes. That's a good point. In the IPv4 NETDEV_REGISTER case the treatment
ends at the point, when (dev->mtu < 68) is checked as the CAN MTU is 16.
But we also had a problem with the IPv6 NETDEV_REGISTER in addr_conf
(fixed in 2.6.21) that complained about an interface with a too small MTU.
> The core point being that CAN devices as currently constructed are not
> in a closed ecosystem. Other networking layers see them even if they
> can not use the properly.
>
> I don't know what all of the implications are but I do know we
> need to be careful.
>
ACK.
>
> Hmm. My gut feel says that we just want function your drivers can
> call post transmit that will call dev_queue_xmit_nit if someone else
> is watching. Although calling netif_rx seems to work but at least
> in the general case with routing I would be concerned that would get
> you into packets that would get routed out the incoming interface
> and cause a loop.
>
All incoming (and even the 'echoed') CAN frames are processed in
can_rcv() to check the various CAN filters the users may have registered
through their different open AF_CAN sockets. This is a one way receive
path, that leads to simple a kfree_skb() if there's no subscriber for
the received frame. So there is no way to send CAN frames to a CAN
interface when is is not explicitly triggered from the user. CAN has no
routing by design. After looking into dev_queue_xmit_nit() it looks like
netif_rx() was a good choice.
>
> Further I still don't see any mechanism that isolates CAN netdrivers
> from the other protocol layers.
>
> What makes this problem a little stronger is that I have been
> simplifying some of the tests in some of the other networking layers
> from being "if (dev == loopback_dev)" to "if (dev->flags &
> IFF_LOOPBACK)" So there are fewer special cases I need to deal with.
>
> I believe that if you now use your current CAN patches unless I have
> misread something your can devices will now show up with ip 127.0.0.1
>
No they don't due to the described mtu size verification. BUT i now get
an idea, why IFF_LOOPBACK was not that good approach ;-)
>
>> I don't have any concerns creating a new IFF_-flag for this "loopback
>> approved by CSMA/CA media access" i just have no idea for a really good
>> name for it. But maybe the use of IFF_LOOPBACK for CAN netdrivers
>> (ARPHRD_CAN) is also ok for you now?!?
>>
>
> Serial devices tend to call this echo or local echo, so how about
> IFF_ECHO.
>
Excellent suggestion! If there are no remarks from other people, we can
change this in our next posting and add a new IFF_ECHO to if.h. Indeed
it's worth to look on the currently defined CAN RAW sockopts, the CAN
source and the docs to globally replace the 'loopback' with 'echo'. The
'local echo' hits the point really much better than to describe the
'loopback'-mechanic that's behind.
Thanks very much for your feedback & your time to review our stuff!
Oliver
^ permalink raw reply
* Re: [stable] Upgrading 2.6.21.7->2.6.22.9 kills my network (sky2): sky2 eth0: rx error, status 0x402300 length 60
From: Krzysztof Oledzki @ 2007-09-28 18:36 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Hemminger, Linux Netdev List, stable
In-Reply-To: <20070928161328.GB28246@kroah.com>
On Fri, 28 Sep 2007, Greg KH wrote:
> On Fri, Sep 28, 2007 at 01:11:27PM +0200, Krzysztof Oledzki wrote:
>>
>>
>> On Fri, 28 Sep 2007, Krzysztof Oledzki wrote:
>>
>>>
>>>
>>> On Fri, 28 Sep 2007, Krzysztof Oledzki wrote:
>>>
>>>> Hello,
>>>> After upgrading my kernel from 2.6.21.7 to 2.6.22.9 my 88E8053 no longer
>>>> works:
>>>
>>> Small update: 2.6.22.9 with sky2.c/sky2.h from 2.4.22.4 works without any
>>> problems.
>>
>> Final update.
>>
>> Reverting this patch:
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commitdiff_plain;h=8c07a8e30ba8a2e0831da4b134202598435f8358
>> solved my problem.
>>
>> I also found this one:
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=d6532232cd3de79c852685823a9c52f723816d0a
>>
>> Could it go to a next -stable ASAP, please? It seems that 2.6.22.5-2.6.22.9
>> kernels have broken sky2 if used with vlans. :( Such regression in a
>> -stable kernel isn't nice. :(
>
> So should we just apply the second patch? I'll let Stephen tell us what
> we should do :)
>
Second patch works for me, so IMHO yes. Forget to mention that earlier,
sorry. Ofcourse this should be the maintainer decision, this is only my
vote. :)
^ permalink raw reply
* Re: [PATCH] sb1250-mac: Driver model & phylib update
From: Andrew Morton @ 2007-09-28 18:39 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Jeff Garzik, netdev, linux-mips, linux-kernel
In-Reply-To: <Pine.LNX.4.64N.0709281628130.10439@blysk.ds.pg.gda.pl>
On Fri, 28 Sep 2007 17:23:00 +0100 (BST) "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
> On Mon, 24 Sep 2007, Andrew Morton wrote:
>
> > > Well, this is against Jeff's netdev-2.6 tree which hopefully is not as
> > > crufty as Linus's old mainline; if it is not possible to queue this change
> > > for 2.6.25 or suchlike, then I will try to resubmit later.
> >
> > Most of Jeff's netdev tree got dumped into Dave's net-2.6.24 tree. That's
> > the one you want to be raising patches against for the next few weeks.
>
> OK, thanks for clarification. Then both patches already submitted:
>
> patch-netdev-2.6.23-rc6-20070920-sb1250-mac-typedef-9
> patch-netdev-2.6.23-rc6-20070920-sb1250-mac-29
>
> apply cleanly to net-2.6.24 one on top of the other in this order.
<checks the netdev archives>
hm, I found a patch at the end of an email trail which is datestamped Sep
20 here which appears to match the first one you mentioned, but I'm having
trouble working out what patch subject your "sb1250-mac" maps onto.
This is why I make the patch filenames map directly from the patch titles,
so I end up with files like
optimize-x86-page-faults-like-all-other-achitectures-and-kill-notifier-cruft.patch.
Verbose, but it reduces confusion and mistakes.
> I can resubmit them
That's always a good choice. Patches which are dangling at the end of an email
discussion often don't get merged: it is unclear to the receiveing party that
the discussion has terminated, and I'm never terribly confident in the testing
level of a patch which obviously got modified two minutes before it was sent.
> -- where? netdev? As I say I am fine with 2.6.25 as
> the target.
jeff, netdev, me?
^ permalink raw reply
* Re: [PATCH 2/3] sky2: fix VLAN receive processing
From: Krzysztof Oledzki @ 2007-09-28 18:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Greg KH, stable, netdev, Pierre-Yves Ritschard
In-Reply-To: <20070928164858.539587428@linux-foundation.org>
On Fri, 28 Sep 2007, Stephen Hemminger wrote:
> The length check for truncated frames was not correctly handling
> the case where VLAN acceleration had already read the tag.
> Also, the Yukon EX has some features that use high bit of status
> as security tag.
>
Thank you.
Best regards
Krzysztof Oledzki
^ permalink raw reply
* Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
From: Ilpo Järvinen @ 2007-09-28 19:10 UTC (permalink / raw)
To: Cedric Le Goater; +Cc: Andrew Morton, LKML, Netdev, David Miller
In-Reply-To: <46FD20F0.3050909@fr.ibm.com>
On Fri, 28 Sep 2007, Cedric Le Goater wrote:
> Hello !
>
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/
>
> I just found that warning in my logs. It seems that it's been
> happening since rc7-mm1 at least.
>
> Thanks !
>
> C.
>
> WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 tcp_fastretrans_alert()
>
> Call Trace:
> <IRQ> [<ffffffff8040fdc3>] tcp_ack+0xcd6/0x1894
> ...snip...
...Thanks for the report, I'll have look what could still break
fackets_out...
--
i.
^ permalink raw reply
* Re: [stable] [PATCH 2/3] sky2: fix VLAN receive processing
From: Chris Wright @ 2007-09-28 19:20 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Krzysztof Oledzki, Greg KH, netdev, stable, Pierre-Yves Ritschard
In-Reply-To: <20070928164858.539587428@linux-foundation.org>
* Stephen Hemminger (shemminger@linux-foundation.org) wrote:
> The length check for truncated frames was not correctly handling
> the case where VLAN acceleration had already read the tag.
> Also, the Yukon EX has some features that use high bit of status
> as security tag.
Did you leave out the GMR_FS_LEN change on purpose? AFAICT, w/out
that you miss the Yukon EX high bit usage. The upstream patch applies,
can we simply use that one (below rediffed for stable)?
thanks,
-chris
--
>From d6532232cd3de79c852685823a9c52f723816d0a Mon Sep 17 00:00:00 2001
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Wed, 19 Sep 2007 15:36:42 -0700
Subject: sky2: fix VLAN receive processing (resend)
The length check for truncated frames was not correctly handling
the case where VLAN acceleration had already read the tag.
Also, the Yukon EX has some features that use high bit of status
as security tag.
Signed-off-by: Pierre-Yves Ritschard <pyr@spootnik.org>
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
---
drivers/net/sky2.c | 14 +++++++++++++-
drivers/net/sky2.h | 2 +-
2 files changed, 14 insertions(+), 2 deletions(-)
--- linux-2.6.22.9.orig/drivers/net/sky2.c
+++ linux-2.6.22.9/drivers/net/sky2.c
@@ -2049,6 +2049,13 @@ static struct sk_buff *sky2_receive(stru
struct sky2_port *sky2 = netdev_priv(dev);
struct rx_ring_info *re = sky2->rx_ring + sky2->rx_next;
struct sk_buff *skb = NULL;
+ u16 count = (status & GMR_FS_LEN) >> 16;
+
+#ifdef SKY2_VLAN_TAG_USED
+ /* Account for vlan tag */
+ if (sky2->vlgrp && (status & GMR_FS_VLAN))
+ count -= VLAN_HLEN;
+#endif
if (unlikely(netif_msg_rx_status(sky2)))
printk(KERN_DEBUG PFX "%s: rx slot %u status 0x%x len %d\n",
@@ -2063,7 +2070,8 @@ static struct sk_buff *sky2_receive(stru
if (!(status & GMR_FS_RX_OK))
goto resubmit;
- if (status >> 16 != length)
+ /* if length reported by DMA does not match PHY, packet was truncated */
+ if (length != count)
goto len_mismatch;
if (length < copybreak)
@@ -2079,6 +2087,10 @@ len_mismatch:
/* Truncation of overlength packets
causes PHY length to not match MAC length */
++sky2->net_stats.rx_length_errors;
+ if (netif_msg_rx_err(sky2) && net_ratelimit())
+ pr_info(PFX "%s: rx length mismatch: length %d status %#x\n",
+ dev->name, length, status);
+ goto resubmit;
error:
++sky2->net_stats.rx_errors;
--- linux-2.6.22.9.orig/drivers/net/sky2.h
+++ linux-2.6.22.9/drivers/net/sky2.h
@@ -1579,7 +1579,7 @@ enum {
/* Receive Frame Status Encoding */
enum {
- GMR_FS_LEN = 0xffff<<16, /* Bit 31..16: Rx Frame Length */
+ GMR_FS_LEN = 0x7fff<<16, /* Bit 30..16: Rx Frame Length */
GMR_FS_VLAN = 1<<13, /* VLAN Packet */
GMR_FS_JABBER = 1<<12, /* Jabber Packet */
GMR_FS_UN_SIZE = 1<<11, /* Undersize Packet */
^ permalink raw reply
* Re: [stable] [PATCH 2/3] sky2: fix VLAN receive processing
From: Stephen Hemminger @ 2007-09-28 19:36 UTC (permalink / raw)
To: Chris Wright
Cc: Krzysztof Oledzki, Greg KH, netdev, stable, Pierre-Yves Ritschard
In-Reply-To: <20070928192044.GH3906@sequoia.sous-sol.org>
On Fri, 28 Sep 2007 12:20:44 -0700
Chris Wright <chrisw@sous-sol.org> wrote:
> * Stephen Hemminger (shemminger@linux-foundation.org) wrote:
> > The length check for truncated frames was not correctly handling
> > the case where VLAN acceleration had already read the tag.
> > Also, the Yukon EX has some features that use high bit of status
> > as security tag.
>
> Did you leave out the GMR_FS_LEN change on purpose? AFAICT, w/out
> that you miss the Yukon EX high bit usage. The upstream patch applies,
> can we simply use that one (below rediffed for stable)?
>
> thanks,
> -chris
>
I left it out on purpose because 2.6.22 doesn't support Yukon EX.
^ permalink raw reply
* Re: [stable] [PATCH 2/3] sky2: fix VLAN receive processing
From: Chris Wright @ 2007-09-28 19:41 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Chris Wright, Greg KH, netdev, stable, Pierre-Yves Ritschard,
Krzysztof Oledzki
In-Reply-To: <20070928123621.6a430736@freepuppy.rosehill>
* Stephen Hemminger (shemminger@linux-foundation.org) wrote:
> I left it out on purpose because 2.6.22 doesn't support Yukon EX.
OK, thanks.
^ permalink raw reply
* Re: [ofa-general] [PATCH v3] iw_cxgb3: Support"iwarp-only"interfacesto avoid 4-tuple conflicts.
From: Steve Wise @ 2007-09-28 19:46 UTC (permalink / raw)
To: Kanevsky, Arkady
Cc: Sean Hefty, Sean Hefty, netdev, rdreier, linux-kernel, general
In-Reply-To: <C98692FD98048C41885E0B0FACD9DFB80518755A@exnane01.hq.netapp.com>
Kanevsky, Arkady wrote:
> Sean,
> IB aside,
> it looks like an ULP which is capable of being both RDMA aware and RDMA
> not-aware,
> like iSER and iSCSI, NFS-RDMA and NFS, SDP and sockets,
> will be treated as two separete ULPs.
> Each has its own IP address, since there is a different IP address for
> iWARP
> port and "regular" Ethernet port. So it falls on the users of ULPs to
> "handle" it
> via DNS or some other services.
> Is this "acceptable" to users? I doubt it.
>
> Recall that ULPs are going in opposite directions by having a different
> port number for RDMA aware and RDMA unaware versions of the ULP.
> This way, ULP "connection manager" handles RDMA-ness under the covers,
> while users plug an IP address for a server to connect to.
> Thanks,
Arkady, I'm confused about how this proposed design changes the behavior
of the ULPs that run on TCP and iWARP. I don't see much difference from
the point of view of the ULPs.
The NFS-RDMA server, for example, will not need to change since it binds
to address 0.0.0.0 which will translate into a bind/listen on the
specific iwarp address for each iwarp device on the rdma side, and
address 0.0.0.0 for the TCP side.
Am I missing your point?
The real pain, IMO, with this solution is that it FORCES the admins to
use 2 subnets when 1 is sufficient if the net maintainers would unify
the port space...
Steve.
>
> Arkady Kanevsky email: arkady@netapp.com
> Network Appliance Inc. phone: 781-768-5395
> 1601 Trapelo Rd. - Suite 16. Fax: 781-895-1195
> Waltham, MA 02451 central phone: 781-768-5300
>
>
>> -----Original Message-----
>> From: Sean Hefty [mailto:sean.hefty@intel.com]
>> Sent: Thursday, September 27, 2007 3:12 PM
>> To: Kanevsky, Arkady; Sean Hefty; Steve Wise
>> Cc: netdev@vger.kernel.org; rdreier@cisco.com;
>> linux-kernel@vger.kernel.org; general@lists.openfabrics.org
>> Subject: RE: [ofa-general] [PATCH v3] iw_cxgb3:
>> Support"iwarp-only"interfacesto avoid 4-tuple conflicts.
>>
>>> What is the model on how client connects, say for iSCSI, when client
>>> and server both support, iWARP and 10GbE or 1GbE, and would like to
>>> setup "most" performant "connection" for ULP?
>> For the "most" performance connection, the ULP would use IB,
>> and all these problems go away. :)
>>
>> This proposal is for each iwarp interface to have its own IP
>> address. Clients would need an iwarp usable address of the
>> server and would connect using rdma_connect(). If that call
>> (or rdma_resolve_addr/route) fails, the client could try
>> connecting using sockets, aoi, or some other interface. I
>> don't see that Steve's proposal changes anything from the
>> client's perspective.
>>
>> - Sean
>> _______________________________________________
>> 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
* 2.6.23-rc[68]-mm: network hangs
From: Laurent Riffard @ 2007-09-28 19:48 UTC (permalink / raw)
To: Kernel development list, netdev
[-- Attachment #1: Type: text/plain, Size: 851 bytes --]
Hi,
>From time to time, I experience some complete network hangs:
Suddenly, all network connections become unresponsive. Even "ping
127.0.0.1" doesn't work. SysRq-w does not show any blocked processus.
When such hang happen, I have to reboot (shutdown does work).
This is not easily reproducible: it happens several minutes after
boot (could be 45 minutes or 2 hours). I do not use heavy networking
apps (like P2P). My typical usage is a Gnome desktop with browser,
mailer, IM, video or audio streaming.
I have a single PC connected to a DSL router via ethernet (so no LAN
with NFS or CIFS).
This happens with 2.6.23-rc8-mm2 and 2.6.23-rc6-mm1. I can't remember
when I first see this problem. Maybe 2 months ago.
I attached the output of "strace ping 127.0.0.1". How can I collect
some more data when this problem happens ?
~~
laurent
[-- Attachment #2: ping.strace --]
[-- Type: text/plain, Size: 7459 bytes --]
execve("/bin/ping", ["ping", "127.0.0.1"], [/* 42 vars */]) = 0
brk(0) = 0x93ac000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f9b000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=57464, ...}) = 0
mmap2(NULL, 57464, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f8c000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libresolv.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0!\0\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=67408, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f8b000
mmap2(NULL, 75976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f78000
mmap2(0xb7f87000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0xb7f87000
mmap2(0xb7f89000, 6344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f89000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0`\1\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1307104, ...}) = 0
mmap2(NULL, 1312164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e37000
mmap2(0xb7f72000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13b) = 0xb7f72000
mmap2(0xb7f75000, 9636, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f75000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e36000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e366c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7f72000, 4096, PROT_READ) = 0
munmap(0xb7f8c000, 57464) = 0
socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
getuid32() = 0
setuid32(0) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(44103), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
close(4) = 0
setsockopt(3, SOL_RAW, ICMP_FILTER, ~(ICMP_ECHOREPLY|ICMP_DEST_UNREACH|ICMP_SOURCE_QUENCH|ICMP_REDIRECT|ICMP_TIME_EXCEEDED|ICMP_PARAMETERPROB), 4) = 0
setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [324], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [65536], 4) = 0
getsockopt(3, SOL_SOCKET, SO_RCVBUF, [131072], [4]) = 0
brk(0) = 0x93ac000
brk(0x93cd000) = 0x93cd000
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f9a000
write(1, "PING 127.0.0.1 (127.0.0.1) 56(84"..., 49) = 49
setsockopt(3, SOL_SOCKET, SO_TIMESTAMP, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_SNDTIMEO, "\1\0\0\0\0\0\0\0", 8) = 0
setsockopt(3, SOL_SOCKET, SO_RCVTIMEO, "\1\0\0\0\0\0\0\0", 8) = 0
getpid() = 9353
rt_sigaction(SIGINT, {0x804b5b0, [], SA_INTERRUPT}, NULL, 8) = 0
rt_sigaction(SIGALRM, {0x804b5b0, [], SA_INTERRUPT}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x804b5c0, [], SA_INTERRUPT}, NULL, 8) = 0
gettimeofday({1190968694, 793502}, NULL) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=52, ws_col=157, ws_xpixel=0, ws_ypixel=0}) = 0
gettimeofday({1190968694, 793762}, NULL) = 0
gettimeofday({1190968694, 793824}, NULL) = 0
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\10\0$\266\211$\0\1v\275\374F\340\34\f\0\10\t\n\v\f\r\16"..., 64}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, 0xbf982e34, 0) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1190968695, 793022}, NULL) = 0
gettimeofday({1190968695, 793096}, NULL) = 0
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\10\0\373\267\211$\0\2w\275\374F\10\32\f\0\10\t\n\v\f\r"..., 64}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, 0xbf982e34, 0) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1190968696, 793050}, NULL) = 0
gettimeofday({1190968696, 793123}, NULL) = 0
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\10\0\337\266\211$\0\3x\275\374F#\32\f\0\10\t\n\v\f\r\16"..., 64}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, 0xbf982e34, 0) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1190968697, 793184}, NULL) = 0
gettimeofday({1190968697, 793259}, NULL) = 0
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\10\0V\265\211$\0\4y\275\374F\253\32\f\0\10\t\n\v\f\r\16"..., 64}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, 0xbf982e34, 0) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1190968698, 793171}, NULL) = 0
gettimeofday({1190968698, 793244}, NULL) = 0
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\10\0d\264\211$\0\5z\275\374F\234\32\f\0\10\t\n\v\f\r\16"..., 64}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, 0xbf982e34, 0) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1190968699, 793234}, NULL) = 0
gettimeofday({1190968699, 793306}, NULL) = 0
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\10\0%\263\211$\0\6{\275\374F\332\32\f\0\10\t\n\v\f\r\16"..., 64}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, 0xbf982e34, 0) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1190968700, 793319}, NULL) = 0
gettimeofday({1190968700, 793393}, NULL) = 0
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\10\0\315\261\211$\0\7|\275\374F1\33\f\0\10\t\n\v\f\r\16"..., 64}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, 0xbf982e34, 0) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1190968701, 793371}, NULL) = 0
gettimeofday({1190968701, 793445}, NULL) = 0
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\10\0\230\260\211$\0\10}\275\374Fe\33\f\0\10\t\n\v\f\r"..., 64}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, 0xbf982e34, 0) = -1 EINTR (Interrupted system call)
--- SIGINT (Interrupt) @ 0 (0) ---
sigreturn() = ? (mask now [])
write(1, "\n", 1) = 1
write(1, "--- 127.0.0.1 ping statistics --"..., 34) = 34
write(1, "8 packets transmitted, 0 receive"..., 65) = 65
write(1, "\n", 1) = 1
exit_group(1) = ?
^ permalink raw reply
* Re: [RFC/PATCH 1/3] UDP memory usage accounting (take 2): fix send buffer check
From: David Miller @ 2007-09-28 20:09 UTC (permalink / raw)
To: satoshi.oshima.fk
Cc: andi, johnpol, netdev, yumiko.sugita.yf, haoki, yoshfuji
In-Reply-To: <46FD03B2.1000706@hitachi.com>
From: Satoshi OSHIMA <satoshi.oshima.fk@hitachi.com>
Date: Fri, 28 Sep 2007 22:37:54 +0900
> } else if (i < MAX_SKB_FRAGS) {
>
> + if (atomic_read(&sk->sk_wmem_alloc) + PAGE_SIZE
>
> + > 2 * sk->sk_sndbuf) {
>
> + err = -ENOBUFS;
>
> + goto error;
>
> + }
Your email client, or something, is adding newlines every
other line of real content, making your patches unusable.
Please go and perform some testing to make sure that the
patches you email out are untouched by the email client and
can be applied by the recipient.
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: David Miller @ 2007-09-28 20:20 UTC (permalink / raw)
To: tglx; +Cc: urs, shemminger, netdev, kaber, joe, oliver, oliver.hartkopp
In-Reply-To: <1190996839.18681.68.camel@chaos>
From: Thomas Gleixner <tglx@linutronix.de>
Date: Fri, 28 Sep 2007 18:27:19 +0200
> I'm not inclined either way and we really should not make this a
> religious question whether that code goes in or not, especially not when
> we granted the mac80211 to export everything w/o _GPL suffix not too
> long ago.
This is because a wireless driver is a driver. It can exist outside
of the kernel and it's mac80211 stack just like any other network
device driver. ANd the interfaces in mac80211 are such that the
driver doesn't explicitly go into the internals of the implementation.
That's not true with CAN.
With this CAN stuff, any driver you write for it is intimately
integrated into the design and architecture of the CAN subsystem. Any
such driver cannot stand on it's own. Look at how these drivers can
get into the internals.
If this code goes in without the _GPL() exports, that's fine, but it's
setting incorrect expectations for people who think they can write
binary-only drivers and link to these symbols.
And it will be the CAN folks who are guilty of setting these
false premises. Especially after I've explicitly warned about
it here.
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: Thomas Gleixner @ 2007-09-28 20:28 UTC (permalink / raw)
To: David Miller; +Cc: urs, shemminger, netdev, kaber, joe, oliver, oliver.hartkopp
In-Reply-To: <20070928.132038.35678834.davem@davemloft.net>
On Fri, 2007-09-28 at 13:20 -0700, David Miller wrote:
> That's not true with CAN.
>
> With this CAN stuff, any driver you write for it is intimately
> integrated into the design and architecture of the CAN subsystem. Any
> such driver cannot stand on it's own. Look at how these drivers can
> get into the internals.
I'm just concerned about protocols, which have been designed and
implemented long ago outside of the kernel and are going to be wrapped
with glue code to fit into the socket can implementation. That's hard to
judge.
> If this code goes in without the _GPL() exports, that's fine, but it's
> setting incorrect expectations for people who think they can write
> binary-only drivers and link to these symbols.
>
> And it will be the CAN folks who are guilty of setting these
> false premises. Especially after I've explicitly warned about
> it here.
Fair enough.
tglx
^ permalink raw reply
* RE: [ofa-general] [PATCH v3] iw_cxgb3: Support"iwarp-only"interfacesto avoid 4-tuple conflicts.
From: Kanevsky, Arkady @ 2007-09-28 20:36 UTC (permalink / raw)
To: Steve Wise; +Cc: netdev, rdreier, linux-kernel, general
In-Reply-To: <46FD5A2F.7010409@opengridcomputing.com>
Exactly,
it forces the burden on administrator.
And one will be forced to try one mount for iWARP and it does not
work issue another one TCP or UDP if it fails.
Yack!
And server will need to listen on different IP address and simple
* will not work since it will need to listen in two different domains.
Had we run this proposal by administrators?
Thanks,
Arkady Kanevsky email: arkady@netapp.com
Network Appliance Inc. phone: 781-768-5395
1601 Trapelo Rd. - Suite 16. Fax: 781-895-1195
Waltham, MA 02451 central phone: 781-768-5300
> -----Original Message-----
> From: Steve Wise [mailto:swise@opengridcomputing.com]
> Sent: Friday, September 28, 2007 3:47 PM
> To: Kanevsky, Arkady
> Cc: Sean Hefty; Sean Hefty; netdev@vger.kernel.org;
> rdreier@cisco.com; linux-kernel@vger.kernel.org;
> general@lists.openfabrics.org
> Subject: Re: [ofa-general] [PATCH v3] iw_cxgb3:
> Support"iwarp-only"interfacesto avoid 4-tuple conflicts.
>
>
>
> Kanevsky, Arkady wrote:
> > Sean,
> > IB aside,
> > it looks like an ULP which is capable of being both RDMA aware and
> > RDMA not-aware, like iSER and iSCSI, NFS-RDMA and NFS, SDP and
> > sockets, will be treated as two separete ULPs.
> > Each has its own IP address, since there is a different IP
> address for
> > iWARP port and "regular" Ethernet port. So it falls on the users of
> > ULPs to "handle" it via DNS or some other services.
> > Is this "acceptable" to users? I doubt it.
> >
> > Recall that ULPs are going in opposite directions by having a
> > different port number for RDMA aware and RDMA unaware
> versions of the ULP.
> > This way, ULP "connection manager" handles RDMA-ness under
> the covers,
> > while users plug an IP address for a server to connect to.
> > Thanks,
>
> Arkady, I'm confused about how this proposed design changes
> the behavior of the ULPs that run on TCP and iWARP. I don't
> see much difference from the point of view of the ULPs.
>
> The NFS-RDMA server, for example, will not need to change
> since it binds to address 0.0.0.0 which will translate into a
> bind/listen on the specific iwarp address for each iwarp
> device on the rdma side, and address 0.0.0.0 for the TCP side.
>
> Am I missing your point?
>
> The real pain, IMO, with this solution is that it FORCES the
> admins to use 2 subnets when 1 is sufficient if the net
> maintainers would unify the port space...
>
> Steve.
>
>
>
> >
> > Arkady Kanevsky email: arkady@netapp.com
> > Network Appliance Inc. phone: 781-768-5395
> > 1601 Trapelo Rd. - Suite 16. Fax: 781-895-1195
> > Waltham, MA 02451 central phone: 781-768-5300
> >
> >
> >> -----Original Message-----
> >> From: Sean Hefty [mailto:sean.hefty@intel.com]
> >> Sent: Thursday, September 27, 2007 3:12 PM
> >> To: Kanevsky, Arkady; Sean Hefty; Steve Wise
> >> Cc: netdev@vger.kernel.org; rdreier@cisco.com;
> >> linux-kernel@vger.kernel.org; general@lists.openfabrics.org
> >> Subject: RE: [ofa-general] [PATCH v3] iw_cxgb3:
> >> Support"iwarp-only"interfacesto avoid 4-tuple conflicts.
> >>
> >>> What is the model on how client connects, say for iSCSI,
> when client
> >>> and server both support, iWARP and 10GbE or 1GbE, and
> would like to
> >>> setup "most" performant "connection" for ULP?
> >> For the "most" performance connection, the ULP would use
> IB, and all
> >> these problems go away. :)
> >>
> >> This proposal is for each iwarp interface to have its own
> IP address.
> >> Clients would need an iwarp usable address of the server and would
> >> connect using rdma_connect(). If that call (or
> >> rdma_resolve_addr/route) fails, the client could try
> connecting using
> >> sockets, aoi, or some other interface. I don't see that Steve's
> >> proposal changes anything from the client's perspective.
> >>
> >> - Sean
> >> _______________________________________________
> >> 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: [ofa-general] [PATCH v3] iw_cxgb3: Support"iwarp-only"interfacesto avoid 4-tuple conflicts.
From: Steve Wise @ 2007-09-28 21:27 UTC (permalink / raw)
To: Kanevsky, Arkady
Cc: Sean Hefty, Sean Hefty, netdev, rdreier, linux-kernel, general
In-Reply-To: <C98692FD98048C41885E0B0FACD9DFB805187762@exnane01.hq.netapp.com>
Kanevsky, Arkady wrote:
> Exactly,
> it forces the burden on administrator.
> And one will be forced to try one mount for iWARP and it does not
> work issue another one TCP or UDP if it fails.
> Yack!
>
I see your point. I have no defense. My hands have been tied on fixing
this properly...
> And server will need to listen on different IP address and simple
> * will not work since it will need to listen in two different domains.
>
No, the server will listen on 0.0.0.0:2049 for TCP, and 0.0.0.0:2050 for
rdma. The rdma subsystem will translate 0.0.0.0:2050 into listens on
specific iwarp ip addresses on every iwarp device...
> Had we run this proposal by administrators?
There has been no other solution proposed that Dave Miller and Jeff
Garzik won't NAK...
Steve.
^ permalink raw reply
* Re: error(s) in 2.6.23-rc5 bonding.txt ?
From: Rick Jones @ 2007-09-28 21:31 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Linux Network Development list
In-Reply-To: <3360.1189213298@death>
Well, I managed to concoct an updated test, this time with 1G's going into a
10G. A 2.6.23-rc8 kernel on the system with four, dual-port 82546GB's,
connected to an HP ProCurve 3500 series switch with a 10G link to a system
running 2.6.18-8.el5 (I was having difficulty getting cxgb3 going on my
kernel.org kernels - firmware mismatches - so I booted RHEL5 there).
I put all four 1G interfaces into a balance_rr (mode=0) bond and started running
just a single netperf TCP_STREAM test.
On the bonding side:
hpcpc103:~/net-2.6.24/Documentation/networking# netstat -s -t | grep retran
19050 segments retransmited
9349 fast retransmits
9698 forward retransmits
hpcpc103:~/net-2.6.24/Documentation/networking# ifconfig bond0 | grep pack
RX packets:50708119 errors:0 dropped:0 overruns:0 frame:0
TX packets:58801285 errors:0 dropped:0 overruns:0 carrier:0
hpcpc103:~/net-2.6.24/Documentation/networking# netperf -H 192.168.5.106
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.5.106
(192.168.5.106) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.01 1267.99
hpcpc103:~/net-2.6.24/Documentation/networking# netstat -s -t | grep retran
20268 segments retransmited
9974 fast retransmits
10291 forward retransmits
hpcpc103:~/net-2.6.24/Documentation/networking# ifconfig bond0 | grep pack
RX packets:51636421 errors:0 dropped:0 overruns:0 frame:0
TX packets:59899089 errors:0 dropped:0 overruns:0 carrier:0
on the recieving side:
[root@hpcpc106 ~]# ifconfig eth5 | grep pack
RX packets:58802455 errors:0 dropped:0 overruns:0 frame:0
TX packets:50205304 errors:0 dropped:0 overruns:0 carrier:0
[root@hpcpc106 ~]# ifconfig eth5 | grep pack
RX packets:59900267 errors:0 dropped:0 overruns:0 frame:0
TX packets:51124138 errors:0 dropped:0 overruns:0 carrier:0
So, there were 20268 - 19050 or 1218 retransmissions during the test. The
sending side reported sending 59899089 - 58801285 or 1097804 packets, and the
receiver reported receiving 59900267 - 58802455 or 1097812 packets.
Unless the switch was only occasionally duplicating segments or something, it
looks like all the retransmissions were the result of duplicate ACKs from packet
reordering.
For grins I varied the "reordering" sysctl and got:
# netstat -s -t | grep retran; for i in 3 4 5 6 7 8 9 10 20 30; do sysctl -w
net.ipv4.tcp_reordering=$i; netperf -H 192.168.5.106 -P 0 -B "reorder $i";
netstat -s -t | grep retran; done
13735 segments retransmited
6581 fast retransmits
7151 forward retransmits
net.ipv4.tcp_reordering = 3
87380 16384 16384 10.01 1294.51 reorder 3
15127 segments retransmited
7330 fast retransmits
7794 forward retransmits
net.ipv4.tcp_reordering = 4
87380 16384 16384 10.01 1304.22 reorder 4
16103 segments retransmited
7807 fast retransmits
8293 forward retransmits
net.ipv4.tcp_reordering = 5
87380 16384 16384 10.01 1330.88 reorder 5
16763 segments retransmited
8155 fast retransmits
8605 forward retransmits
net.ipv4.tcp_reordering = 6
87380 16384 16384 10.01 1350.50 reorder 6
17134 segments retransmited
8356 fast retransmits
8775 forward retransmits
net.ipv4.tcp_reordering = 7
87380 16384 16384 10.01 1353.00 reorder 7
17492 segments retransmited
8553 fast retransmits
8936 forward retransmits
net.ipv4.tcp_reordering = 8
87380 16384 16384 10.01 1358.00 reorder 8
17649 segments retransmited
8625 fast retransmits
9021 forward retransmits
net.ipv4.tcp_reordering = 9
87380 16384 16384 10.01 1415.89 reorder 9
17736 segments retransmited
8666 fast retransmits
9067 forward retransmits
net.ipv4.tcp_reordering = 10
87380 16384 16384 10.01 1412.36 reorder 10
17773 segments retransmited
8684 fast retransmits
9086 forward retransmits
net.ipv4.tcp_reordering = 20
87380 16384 16384 10.01 1403.47 reorder 20
17773 segments retransmited
8684 fast retransmits
9086 forward retransmits
net.ipv4.tcp_reordering = 30
87380 16384 16384 10.01 1325.41 reorder 30
17773 segments retransmited
8684 fast retransmits
9086 forward retransmits
IE fast retrans from reordering until the reorder limit was reasonably well
above the number of links in the aggregate.
As for how things got reordered, knuth knows exactly why. But it didn't need
more than one connection, and that connection didn't have to vary the size of
what it was passing to send(). Netperf was not making send calls which were an
integral multiple of the MSS, which means that from time to time a short segment
would be queued to an interface in the bond. Also, two of the dual-port NICs
were on 66 MHz PCI-X busses, and the other two were on 133MHz PCI-X busses
(four busses in all) so the DMA times will have differed.
And as if this mail wasn't already long enough, here is some tcptrace summary
for the netperf data connection with reorder at 3:
================================
TCP connection 2:
host c: 192.168.5.103:52264
host d: 192.168.5.106:33940
complete conn: yes
first packet: Fri Sep 28 14:06:43.271692 2007
last packet: Fri Sep 28 14:06:53.277018 2007
elapsed time: 0:00:10.005326
total packets: 1556191
filename: trace
c->d: d->c:
total packets: 699400 total packets: 856791
ack pkts sent: 699399 ack pkts sent: 856791
pure acks sent: 2 pure acks sent: 856789
sack pkts sent: 0 sack pkts sent: 352480
dsack pkts sent: 0 dsack pkts sent: 948
max sack blks/ack: 0 max sack blks/ack: 3
unique bytes sent: 1180423912 unique bytes sent: 0
actual data pkts: 699397 actual data pkts: 0
actual data bytes: 1180581744 actual data bytes: 0
rexmt data pkts: 106 rexmt data pkts: 0
rexmt data bytes: 157832 rexmt data bytes: 0
zwnd probe pkts: 0 zwnd probe pkts: 0
zwnd probe bytes: 0 zwnd probe bytes: 0
outoforder pkts: 202461 outoforder pkts: 0
pushed data pkts: 6057 pushed data pkts: 0
SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1
req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y
adv wind scale: 7 adv wind scale: 9
req sack: Y req sack: Y
sacks sent: 0 sacks sent: 352480
urgent data pkts: 0 pkts urgent data pkts: 0 pkts
urgent data bytes: 0 bytes urgent data bytes: 0 bytes
mss requested: 1460 bytes mss requested: 1460 bytes
max segm size: 8688 bytes max segm size: 0 bytes
min segm size: 8 bytes min segm size: 0 bytes
avg segm size: 1687 bytes avg segm size: 0 bytes
max win adv: 5888 bytes max win adv: 968704 bytes
min win adv: 5888 bytes min win adv: 8704 bytes
zero win adv: 0 times zero win adv: 0 times
avg win adv: 5888 bytes avg win adv: 798088 bytes
initial window: 2896 bytes initial window: 0 bytes
initial window: 2 pkts initial window: 0 pkts
ttl stream length: 1577454360 bytes ttl stream length: 0 bytes
missed data: 397030448 bytes missed data: 0 bytes
truncated data: 1159600134 bytes truncated data: 0 bytes
truncated packets: 699383 pkts truncated packets: 0 pkts
data xmit time: 10.005 secs data xmit time: 0.000 secs
idletime max: 7.5 ms idletime max: 7.4 ms
throughput: 117979555 Bps throughput: 0 Bps
This was taken at the receiving 10G NIC.
rick jones
^ permalink raw reply
* Re: [ofa-general] [PATCH v3] iw_cxgb3: Support"iwarp-only"interfacesto avoid 4-tuple conflicts.
From: Sean Hefty @ 2007-09-28 21:34 UTC (permalink / raw)
To: Kanevsky, Arkady
Cc: Steve Wise, Sean Hefty, netdev, rdreier, linux-kernel, general
In-Reply-To: <C98692FD98048C41885E0B0FACD9DFB805187762@exnane01.hq.netapp.com>
Kanevsky, Arkady wrote:
> Exactly,
> it forces the burden on administrator.
> And one will be forced to try one mount for iWARP and it does not
> work issue another one TCP or UDP if it fails.
> Yack!
>
> And server will need to listen on different IP address and simple
> * will not work since it will need to listen in two different domains.
The server already has to call listen twice. Once for the rdma_cm and
once for sockets. Similarly on the client side, connect must be made
over rdma_cm or sockets. I really don't see any impact on the
application for this approach.
We just end up separating the port space based on networking addresses,
rather than keeping the problem at the transport level. If you have an
alternate approach that will be accepted upstream, feel free to post it.
- Sean
^ permalink raw reply
* [PATCH] IPoIB: Convert to netdevice internal stats
From: Roland Dreier @ 2007-09-28 22:18 UTC (permalink / raw)
To: davem, jeff; +Cc: general, netdev
Use the stats member of struct netdevice in IPoIB, so we can save
memory by deleting the stats member of struct ipoib_dev_priv, and save
code by deleting ipoib_get_stats().
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
Dave, can you queue this in net-2.6.24 please? I would ordinarily
merge IPoIB changes but since this depends on the netdevice internal
stats change it becomes a cross-tree dependency if I try to do that.
And I'd like to get it queued in git now before the merge window.
Thanks...
drivers/infiniband/ulp/ipoib/ipoib.h | 2 --
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 20 ++++++++++----------
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 18 +++++++++---------
drivers/infiniband/ulp/ipoib/ipoib_main.c | 22 +++++++---------------
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 10 +++++-----
5 files changed, 31 insertions(+), 41 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h b/drivers/infiniband/ulp/ipoib/ipoib.h
index 3a6ef14..1e627ee 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -300,8 +300,6 @@ struct ipoib_dev_priv {
struct ib_event_handler event_handler;
- struct net_device_stats stats;
-
struct net_device *parent;
struct list_head child_intfs;
struct list_head list;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 08b4676..1afd93c 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -430,7 +430,7 @@ void ipoib_cm_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
ipoib_dbg(priv, "cm recv error "
"(status=%d, wrid=%d vend_err %x)\n",
wc->status, wr_id, wc->vendor_err);
- ++priv->stats.rx_dropped;
+ ++dev->stats.rx_dropped;
goto repost;
}
@@ -457,7 +457,7 @@ void ipoib_cm_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
* this packet and reuse the old buffer.
*/
ipoib_dbg(priv, "failed to allocate receive buffer %d\n", wr_id);
- ++priv->stats.rx_dropped;
+ ++dev->stats.rx_dropped;
goto repost;
}
@@ -474,8 +474,8 @@ void ipoib_cm_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
skb_pull(skb, IPOIB_ENCAP_LEN);
dev->last_rx = jiffies;
- ++priv->stats.rx_packets;
- priv->stats.rx_bytes += skb->len;
+ ++dev->stats.rx_packets;
+ dev->stats.rx_bytes += skb->len;
skb->dev = dev;
/* XXX get correct PACKET_ type here */
@@ -512,8 +512,8 @@ void ipoib_cm_send(struct net_device *dev, struct sk_buff *skb, struct ipoib_cm_
if (unlikely(skb->len > tx->mtu)) {
ipoib_warn(priv, "packet len %d (> %d) too long to send, dropping\n",
skb->len, tx->mtu);
- ++priv->stats.tx_dropped;
- ++priv->stats.tx_errors;
+ ++dev->stats.tx_dropped;
+ ++dev->stats.tx_errors;
ipoib_cm_skb_too_long(dev, skb, tx->mtu - IPOIB_ENCAP_LEN);
return;
}
@@ -532,7 +532,7 @@ void ipoib_cm_send(struct net_device *dev, struct sk_buff *skb, struct ipoib_cm_
tx_req->skb = skb;
addr = ib_dma_map_single(priv->ca, skb->data, skb->len, DMA_TO_DEVICE);
if (unlikely(ib_dma_mapping_error(priv->ca, addr))) {
- ++priv->stats.tx_errors;
+ ++dev->stats.tx_errors;
dev_kfree_skb_any(skb);
return;
}
@@ -542,7 +542,7 @@ void ipoib_cm_send(struct net_device *dev, struct sk_buff *skb, struct ipoib_cm_
if (unlikely(post_send(priv, tx, tx->tx_head & (ipoib_sendq_size - 1),
addr, skb->len))) {
ipoib_warn(priv, "post_send failed\n");
- ++priv->stats.tx_errors;
+ ++dev->stats.tx_errors;
ib_dma_unmap_single(priv->ca, addr, skb->len, DMA_TO_DEVICE);
dev_kfree_skb_any(skb);
} else {
@@ -580,8 +580,8 @@ static void ipoib_cm_handle_tx_wc(struct net_device *dev, struct ipoib_cm_tx *tx
ib_dma_unmap_single(priv->ca, tx_req->mapping, tx_req->skb->len, DMA_TO_DEVICE);
/* FIXME: is this right? Shouldn't we only increment on success? */
- ++priv->stats.tx_packets;
- priv->stats.tx_bytes += tx_req->skb->len;
+ ++dev->stats.tx_packets;
+ dev->stats.tx_bytes += tx_req->skb->len;
dev_kfree_skb_any(tx_req->skb);
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
index b664b98..1a77e79 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -208,7 +208,7 @@ static void ipoib_ib_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
* this packet and reuse the old buffer.
*/
if (unlikely(ipoib_alloc_rx_skb(dev, wr_id))) {
- ++priv->stats.rx_dropped;
+ ++dev->stats.rx_dropped;
goto repost;
}
@@ -225,8 +225,8 @@ static void ipoib_ib_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
skb_pull(skb, IPOIB_ENCAP_LEN);
dev->last_rx = jiffies;
- ++priv->stats.rx_packets;
- priv->stats.rx_bytes += skb->len;
+ ++dev->stats.rx_packets;
+ dev->stats.rx_bytes += skb->len;
skb->dev = dev;
/* XXX get correct PACKET_ type here */
@@ -260,8 +260,8 @@ static void ipoib_ib_handle_tx_wc(struct net_device *dev, struct ib_wc *wc)
ib_dma_unmap_single(priv->ca, tx_req->mapping,
tx_req->skb->len, DMA_TO_DEVICE);
- ++priv->stats.tx_packets;
- priv->stats.tx_bytes += tx_req->skb->len;
+ ++dev->stats.tx_packets;
+ dev->stats.tx_bytes += tx_req->skb->len;
dev_kfree_skb_any(tx_req->skb);
@@ -362,8 +362,8 @@ void ipoib_send(struct net_device *dev, struct sk_buff *skb,
if (unlikely(skb->len > priv->mcast_mtu + IPOIB_ENCAP_LEN)) {
ipoib_warn(priv, "packet len %d (> %d) too long to send, dropping\n",
skb->len, priv->mcast_mtu + IPOIB_ENCAP_LEN);
- ++priv->stats.tx_dropped;
- ++priv->stats.tx_errors;
+ ++dev->stats.tx_dropped;
+ ++dev->stats.tx_errors;
ipoib_cm_skb_too_long(dev, skb, priv->mcast_mtu);
return;
}
@@ -383,7 +383,7 @@ void ipoib_send(struct net_device *dev, struct sk_buff *skb,
addr = ib_dma_map_single(priv->ca, skb->data, skb->len,
DMA_TO_DEVICE);
if (unlikely(ib_dma_mapping_error(priv->ca, addr))) {
- ++priv->stats.tx_errors;
+ ++dev->stats.tx_errors;
dev_kfree_skb_any(skb);
return;
}
@@ -392,7 +392,7 @@ void ipoib_send(struct net_device *dev, struct sk_buff *skb,
if (unlikely(post_send(priv, priv->tx_head & (ipoib_sendq_size - 1),
address->ah, qpn, addr, skb->len))) {
ipoib_warn(priv, "post_send failed\n");
- ++priv->stats.tx_errors;
+ ++dev->stats.tx_errors;
ib_dma_unmap_single(priv->ca, addr, skb->len, DMA_TO_DEVICE);
dev_kfree_skb_any(skb);
} else {
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index d8754dd..e079cca 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -519,7 +519,7 @@ static void neigh_add_path(struct sk_buff *skb, struct net_device *dev)
neigh = ipoib_neigh_alloc(skb->dst->neighbour);
if (!neigh) {
- ++priv->stats.tx_dropped;
+ ++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
return;
}
@@ -584,7 +584,7 @@ err_list:
err_path:
ipoib_neigh_free(dev, neigh);
err_drop:
- ++priv->stats.tx_dropped;
+ ++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
spin_unlock(&priv->lock);
@@ -633,7 +633,7 @@ static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
} else
__path_add(dev, path);
} else {
- ++priv->stats.tx_dropped;
+ ++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
}
@@ -652,7 +652,7 @@ static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
skb_push(skb, sizeof *phdr);
__skb_queue_tail(&path->queue, skb);
} else {
- ++priv->stats.tx_dropped;
+ ++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
}
@@ -720,7 +720,7 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
__skb_queue_tail(&neigh->queue, skb);
spin_unlock(&priv->lock);
} else {
- ++priv->stats.tx_dropped;
+ ++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
}
} else {
@@ -746,7 +746,7 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
IPOIB_QPN(phdr->hwaddr),
IPOIB_GID_RAW_ARG(phdr->hwaddr + 4));
dev_kfree_skb_any(skb);
- ++priv->stats.tx_dropped;
+ ++dev->stats.tx_dropped;
goto out;
}
@@ -760,13 +760,6 @@ out:
return NETDEV_TX_OK;
}
-static struct net_device_stats *ipoib_get_stats(struct net_device *dev)
-{
- struct ipoib_dev_priv *priv = netdev_priv(dev);
-
- return &priv->stats;
-}
-
static void ipoib_timeout(struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
@@ -867,7 +860,7 @@ void ipoib_neigh_free(struct net_device *dev, struct ipoib_neigh *neigh)
struct sk_buff *skb;
*to_ipoib_neigh(neigh->neighbour) = NULL;
while ((skb = __skb_dequeue(&neigh->queue))) {
- ++priv->stats.tx_dropped;
+ ++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
}
if (ipoib_cm_get(neigh))
@@ -950,7 +943,6 @@ static void ipoib_setup(struct net_device *dev)
dev->stop = ipoib_stop;
dev->change_mtu = ipoib_change_mtu;
dev->hard_start_xmit = ipoib_start_xmit;
- dev->get_stats = ipoib_get_stats;
dev->tx_timeout = ipoib_timeout;
dev->hard_header = ipoib_hard_header;
dev->set_multicast_list = ipoib_set_mcast_list;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index 94a5709..8b92ea8 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -103,7 +103,7 @@ static void ipoib_mcast_free(struct ipoib_mcast *mcast)
}
spin_lock_irqsave(&priv->tx_lock, flags);
- priv->stats.tx_dropped += tx_dropped;
+ dev->stats.tx_dropped += tx_dropped;
spin_unlock_irqrestore(&priv->tx_lock, flags);
kfree(mcast);
@@ -298,7 +298,7 @@ ipoib_mcast_sendonly_join_complete(int status,
/* Flush out any queued packets */
spin_lock_irq(&priv->tx_lock);
while (!skb_queue_empty(&mcast->pkt_queue)) {
- ++priv->stats.tx_dropped;
+ ++dev->stats.tx_dropped;
dev_kfree_skb_any(skb_dequeue(&mcast->pkt_queue));
}
spin_unlock_irq(&priv->tx_lock);
@@ -653,7 +653,7 @@ void ipoib_mcast_send(struct net_device *dev, void *mgid, struct sk_buff *skb)
if (!test_bit(IPOIB_MCAST_STARTED, &priv->flags) ||
!priv->broadcast ||
!test_bit(IPOIB_MCAST_FLAG_ATTACHED, &priv->broadcast->flags)) {
- ++priv->stats.tx_dropped;
+ ++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
goto unlock;
}
@@ -668,7 +668,7 @@ void ipoib_mcast_send(struct net_device *dev, void *mgid, struct sk_buff *skb)
if (!mcast) {
ipoib_warn(priv, "unable to allocate memory for "
"multicast structure\n");
- ++priv->stats.tx_dropped;
+ ++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
goto out;
}
@@ -683,7 +683,7 @@ void ipoib_mcast_send(struct net_device *dev, void *mgid, struct sk_buff *skb)
if (skb_queue_len(&mcast->pkt_queue) < IPOIB_MAX_MCAST_QUEUE)
skb_queue_tail(&mcast->pkt_queue, skb);
else {
- ++priv->stats.tx_dropped;
+ ++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
}
^ permalink raw reply related
* Re: [PATCH] IPoIB: Convert to netdevice internal stats
From: David Miller @ 2007-09-28 22:34 UTC (permalink / raw)
To: rdreier; +Cc: davem, jeff, general, netdev
In-Reply-To: <ada641umo2u.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Fri, 28 Sep 2007 15:18:01 -0700
> Use the stats member of struct netdevice in IPoIB, so we can save
> memory by deleting the stats member of struct ipoib_dev_priv, and save
> code by deleting ipoib_get_stats().
>
> Signed-off-by: Roland Dreier <rolandd@cisco.com>
Applied to net-2.6.24, thanks.
How is that ibm_emac NAPI conversion coming along? :-)
^ permalink raw reply
* Re: [PATCH] IPoIB: Convert to netdevice internal stats
From: Roland Dreier @ 2007-09-28 22:36 UTC (permalink / raw)
To: David Miller; +Cc: jeff, general, netdev
In-Reply-To: <20070928.153425.43869012.davem@davemloft.net>
> How is that ibm_emac NAPI conversion coming along? :-)
Sorry, trying to reduce my backlog first, but it is still on my list
of things to work on :)
- R.
^ permalink raw reply
* Re: [RFC] Make TCP prequeue configurable
From: David Miller @ 2007-09-28 22:40 UTC (permalink / raw)
To: jheffner; +Cc: shemminger, dada1, netdev
In-Reply-To: <46FC663A.6030601@psc.edu>
From: John Heffner <jheffner@psc.edu>
Date: Thu, 27 Sep 2007 22:26:02 -0400
> I think it really does help in case (4) with old NICs that don't do rx
> checksumming. I'm not sure how many people really care about this
> anymore, but probably some...?
>
> OTOH, it would be nice to get rid of sysctl_tcp_low_latency.
I know most high end apps use poll() so won't sleep in recvmsg()
directly, but occasisionally they will, and even those that have a
poll() triggered recvmsg() will run the backlog and do prequeue if
packets arrive while they are processing the existing receive packets
which is quite common.
So for any app that ends up doing a prequeue it's a win because there
is the issue of scheduling and cpu usage charging.
If the ACK's are coming out of the stack at the rate that the
application can pull data out of the receive queue, and no faster,
this will pace the sender to send precisely how fast the receiver can
get onto the cpu depending upon load.
Furthermore, prequeue puts the stack input processing work into user
context, which means that the users will be charged more fairly for
the work that is done for them.
When packets get fully processed in softirq context, that's bad
because this is cpu usage which doesn't get charged to the user, and
for TCP input processing this cpu usage is non-trivial and is
multiplied by packet count.
^ permalink raw reply
* SFQ: backport some features from ESFQ (try 4)
From: Corey Hickey @ 2007-09-28 22:52 UTC (permalink / raw)
To: netdev
Patchset try 2 addresses the review by Michael Buesch.
Patchset try 3 addresses the review by Patrick McHardy.
Patchset try 4 has a few cosmetic improvements.
Nobody reviewed my last set of patches, and I wasn't pushy about asking.
Since it's been a while, I ported the kernel and userspace patchsets to
current git of net-2.6 and iproute2, respectively.
The first 7 patches in this series resemble the corresponding 7 patches
in patchset try 2. There aren't any major changes--just modifications
to address errors noticed in review and slight reorganizations to make
the next patches easier.
Patches 8-10 implement parameter passing via nested compat attributes.
This is necessary for using 'tc qdisc change' to disable perturbation.
The rest of the parameters were added for consistency.
Iproute2 patches will follow shortly.
The following is the original patch text.
This set of patches adds some of ESFQ's modifications to the original
SFQ. Thus far, I have received support for this approach rather than for
trying to get ESFQ included as a separate qdisc.
http://mailman.ds9a.nl/pipermail/lartc/2007q2/021056.html
My patches here implement "tc qdisc change", user-configurable depth
(number of flows), and user-configurable divisor (for setting hash table
size). I've left out the remaining ESFQ features (usage of jhash and
different hashing methods) because Patrick McHardy intends to submit a
patch that will supersede that functionality; see the URL above.
Default values remain the same, and SFQ's default behavior remains the
same, so there should be no user disruption.
Thanks for your consideration,
Corey
include/linux/pkt_sched.h | 23 ++--
net/sched/sch_sfq.c | 353 ++++++++++++++++++++++++++++++---------------
2 files changed, 254 insertions(+), 122 deletions(-)
[PATCH 01/10] Preparatory refactoring part 1.
[PATCH 02/10] Preparatory refactoring part 2.
[PATCH 03/10] Move two functions.
[PATCH 04/10] Make "depth" (number of queues) user-configurable:
[PATCH 05/10] Add divisor.
[PATCH 06/10] Make qdisc changeable.
[PATCH 07/10] Remove comments about hardcoded values.
[PATCH 08/10] Multiply perturb_period by HZ when used rather than when assigned.
[PATCH 09/10] Change perturb_period to unsigned.
[PATCH 10/10] Use nested compat attributes to pass parameters.
^ permalink raw reply
* [PATCH 03/10] Move two functions.
From: Corey Hickey @ 2007-09-28 22:52 UTC (permalink / raw)
To: netdev; +Cc: Corey Hickey
In-Reply-To: <1191019977201-git-send-email-bugfood-ml@fatooh.org>
Move sfq_q_destroy() to above sfq_q_init() so that it can be used
by an error case in a later patch.
Move sfq_destroy() as well, for clarity.
Signed-off-by: Corey Hickey <bugfood-ml@fatooh.org>
---
net/sched/sch_sfq.c | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 1ba3d1a..ca22cb7 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -382,6 +382,17 @@ static void sfq_perturbation(unsigned long arg)
}
}
+static void sfq_q_destroy(struct sfq_sched_data *q)
+{
+ del_timer(&q->perturb_timer);
+}
+
+static void sfq_destroy(struct Qdisc *sch)
+{
+ struct sfq_sched_data *q = qdisc_priv(sch);
+ sfq_q_destroy(q);
+}
+
static void
sfq_default_parameters(struct Qdisc *sch)
{
@@ -451,17 +462,6 @@ static int sfq_init(struct Qdisc *sch, struct rtattr *opt)
return 0;
}
-static void sfq_q_destroy(struct sfq_sched_data *q)
-{
- del_timer(&q->perturb_timer);
-}
-
-static void sfq_destroy(struct Qdisc *sch)
-{
- struct sfq_sched_data *q = qdisc_priv(sch);
- sfq_q_destroy(q);
-}
-
static int sfq_dump(struct Qdisc *sch, struct sk_buff *skb)
{
struct sfq_sched_data *q = qdisc_priv(sch);
--
1.5.3
^ permalink raw reply related
* [PATCH 02/10] Preparatory refactoring part 2.
From: Corey Hickey @ 2007-09-28 22:52 UTC (permalink / raw)
To: netdev; +Cc: Corey Hickey
In-Reply-To: <1191019977201-git-send-email-bugfood-ml@fatooh.org>
Factor code out of sfq_init() and sfq_destroy(), again so that the
new functions can be used by sfq_change() later.
Actually, as the diff itself shows, most of the sfq_q_init() code
comes from the original sfq_change(), but sfq_change() is only
called by sfq_init() right now. Thus, it is safe to remove
sfq_change(); "tc qdisc change" doesn't yet work for sfq anyway.
Setting default parameters is moved into a separate function for
clarity.
The sfq_destroy() --> sfq_q_destroy() change looks pointless here,
but it's cleaner to split now and add code to sfq_q_destroy() in a
later patch.
Signed-off-by: Corey Hickey <bugfood-ml@fatooh.org>
---
net/sched/sch_sfq.c | 95 +++++++++++++++++++++++++++++----------------------
1 files changed, 54 insertions(+), 41 deletions(-)
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 57485ef..1ba3d1a 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -382,43 +382,41 @@ static void sfq_perturbation(unsigned long arg)
}
}
-static int sfq_change(struct Qdisc *sch, struct rtattr *opt)
+static void
+sfq_default_parameters(struct Qdisc *sch)
{
struct sfq_sched_data *q = qdisc_priv(sch);
- struct tc_sfq_qopt *ctl = RTA_DATA(opt);
- unsigned int qlen;
-
- if (opt->rta_len < RTA_LENGTH(sizeof(*ctl)))
- return -EINVAL;
-
- sch_tree_lock(sch);
- q->quantum = ctl->quantum ? : psched_mtu(sch->dev);
- q->perturb_period = ctl->perturb_period*HZ;
- if (ctl->limit)
- q->limit = min_t(u32, ctl->limit, SFQ_DEPTH - 2);
- qlen = sch->q.qlen;
- while (sch->q.qlen > q->limit)
- sfq_drop(sch);
- qdisc_tree_decrease_qlen(sch, qlen - sch->q.qlen);
-
- del_timer(&q->perturb_timer);
- if (q->perturb_period) {
- q->perturb_timer.expires = jiffies + q->perturb_period;
- add_timer(&q->perturb_timer);
- }
- sch_tree_unlock(sch);
- return 0;
+ q->quantum = psched_mtu(sch->dev);
+ q->perturbation = 0;
+ q->perturb_period = 0;
+ q->limit = SFQ_DEPTH - 2;
}
-static int sfq_init(struct Qdisc *sch, struct rtattr *opt)
+static int
+sfq_q_init(struct sfq_sched_data *q, struct rtattr *opt)
{
- struct sfq_sched_data *q = qdisc_priv(sch);
int i;
- init_timer(&q->perturb_timer);
- q->perturb_timer.data = (unsigned long)sch;
- q->perturb_timer.function = sfq_perturbation;
+ /* At this point, parameters are set to either defaults (sfq_init) or
+ * the previous values (sfq_change). So, overwrite the parameters as
+ * specified. */
+ if (opt) {
+ struct tc_sfq_qopt *ctl = RTA_DATA(opt);
+
+ if (opt->rta_len < RTA_LENGTH(sizeof(*ctl)))
+ return -EINVAL;
+
+ if (ctl->quantum)
+ q->quantum = ctl->quantum;
+ if (ctl->perturb_period)
+ q->perturb_period = ctl->perturb_period * HZ;
+ if (ctl->limit)
+ q->limit = ctl->limit;
+ }
+ q->limit = min_t(u32, q->limit, SFQ_DEPTH - 2);
+ q->tail = SFQ_DEPTH;
+ q->max_depth = 0;
for (i=0; i<SFQ_HASH_DIVISOR; i++)
q->ht[i] = SFQ_DEPTH;
@@ -427,28 +425,43 @@ static int sfq_init(struct Qdisc *sch, struct rtattr *opt)
q->dep[i+SFQ_DEPTH].next = i+SFQ_DEPTH;
q->dep[i+SFQ_DEPTH].prev = i+SFQ_DEPTH;
}
- q->limit = SFQ_DEPTH - 2;
- q->max_depth = 0;
- q->tail = SFQ_DEPTH;
- if (opt == NULL) {
- q->quantum = psched_mtu(sch->dev);
- q->perturb_period = 0;
- } else {
- int err = sfq_change(sch, opt);
- if (err)
- return err;
- }
+
for (i=0; i<SFQ_DEPTH; i++)
sfq_link(q, i);
return 0;
}
-static void sfq_destroy(struct Qdisc *sch)
+static int sfq_init(struct Qdisc *sch, struct rtattr *opt)
{
struct sfq_sched_data *q = qdisc_priv(sch);
+ int err;
+
+ sfq_default_parameters(sch);
+ if ((err = sfq_q_init(q, opt)))
+ return err;
+
+ init_timer(&q->perturb_timer);
+ q->perturb_timer.data = (unsigned long)sch;
+ q->perturb_timer.function = sfq_perturbation;
+ if (q->perturb_period) {
+ q->perturb_timer.expires = jiffies + q->perturb_period;
+ add_timer(&q->perturb_timer);
+ }
+
+ return 0;
+}
+
+static void sfq_q_destroy(struct sfq_sched_data *q)
+{
del_timer(&q->perturb_timer);
}
+static void sfq_destroy(struct Qdisc *sch)
+{
+ struct sfq_sched_data *q = qdisc_priv(sch);
+ sfq_q_destroy(q);
+}
+
static int sfq_dump(struct Qdisc *sch, struct sk_buff *skb)
{
struct sfq_sched_data *q = qdisc_priv(sch);
--
1.5.3
^ permalink raw reply related
* [PATCH 01/10] Preparatory refactoring part 1.
From: Corey Hickey @ 2007-09-28 22:52 UTC (permalink / raw)
To: netdev; +Cc: Corey Hickey
In-Reply-To: <1191019977201-git-send-email-bugfood-ml@fatooh.org>
Make a new function sfq_q_enqueue() that operates directly on the
queue data. This will be useful for implementing sfq_change() in
a later patch. A pleasant side-effect is reducing most of the
duplicate code in sfq_enqueue() and sfq_requeue().
Similarly, make a new function sfq_q_dequeue().
Signed-off-by: Corey Hickey <bugfood-ml@fatooh.org>
---
net/sched/sch_sfq.c | 72 +++++++++++++++++++++++++++------------------------
1 files changed, 38 insertions(+), 34 deletions(-)
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 3a23e30..57485ef 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -77,6 +77,9 @@
#define SFQ_DEPTH 128
#define SFQ_HASH_DIVISOR 1024
+#define SFQ_HEAD 0
+#define SFQ_TAIL 1
+
/* This type should contain at least SFQ_DEPTH*2 values */
typedef unsigned char sfq_index;
@@ -244,10 +247,9 @@ static unsigned int sfq_drop(struct Qdisc *sch)
return 0;
}
-static int
-sfq_enqueue(struct sk_buff *skb, struct Qdisc* sch)
+static void
+sfq_q_enqueue(struct sk_buff *skb, struct sfq_sched_data *q, unsigned int end)
{
- struct sfq_sched_data *q = qdisc_priv(sch);
unsigned hash = sfq_hash(q, skb);
sfq_index x;
@@ -256,8 +258,12 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc* sch)
q->ht[hash] = x = q->dep[SFQ_DEPTH].next;
q->hash[x] = hash;
}
- sch->qstats.backlog += skb->len;
- __skb_queue_tail(&q->qs[x], skb);
+
+ if (end == SFQ_TAIL)
+ __skb_queue_tail(&q->qs[x], skb);
+ else
+ __skb_queue_head(&q->qs[x], skb);
+
sfq_inc(q, x);
if (q->qs[x].qlen == 1) { /* The flow is new */
if (q->tail == SFQ_DEPTH) { /* It is the first flow */
@@ -270,6 +276,15 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc* sch)
q->tail = x;
}
}
+}
+
+static int
+sfq_enqueue(struct sk_buff *skb, struct Qdisc* sch)
+{
+ struct sfq_sched_data *q = qdisc_priv(sch);
+
+ sfq_q_enqueue(skb, q, SFQ_TAIL);
+ sch->qstats.backlog += skb->len;
if (++sch->q.qlen <= q->limit) {
sch->bstats.bytes += skb->len;
sch->bstats.packets++;
@@ -284,45 +299,21 @@ static int
sfq_requeue(struct sk_buff *skb, struct Qdisc* sch)
{
struct sfq_sched_data *q = qdisc_priv(sch);
- unsigned hash = sfq_hash(q, skb);
- sfq_index x;
- x = q->ht[hash];
- if (x == SFQ_DEPTH) {
- q->ht[hash] = x = q->dep[SFQ_DEPTH].next;
- q->hash[x] = hash;
- }
+ sfq_q_enqueue(skb, q, SFQ_HEAD);
sch->qstats.backlog += skb->len;
- __skb_queue_head(&q->qs[x], skb);
- sfq_inc(q, x);
- if (q->qs[x].qlen == 1) { /* The flow is new */
- if (q->tail == SFQ_DEPTH) { /* It is the first flow */
- q->tail = x;
- q->next[x] = x;
- q->allot[x] = q->quantum;
- } else {
- q->next[x] = q->next[q->tail];
- q->next[q->tail] = x;
- q->tail = x;
- }
- }
if (++sch->q.qlen <= q->limit) {
sch->qstats.requeues++;
return 0;
}
- sch->qstats.drops++;
sfq_drop(sch);
return NET_XMIT_CN;
}
-
-
-
-static struct sk_buff *
-sfq_dequeue(struct Qdisc* sch)
+static struct
+sk_buff *sfq_q_dequeue(struct sfq_sched_data *q)
{
- struct sfq_sched_data *q = qdisc_priv(sch);
struct sk_buff *skb;
sfq_index a, old_a;
@@ -335,8 +326,6 @@ sfq_dequeue(struct Qdisc* sch)
/* Grab packet */
skb = __skb_dequeue(&q->qs[a]);
sfq_dec(q, a);
- sch->q.qlen--;
- sch->qstats.backlog -= skb->len;
/* Is the slot empty? */
if (q->qs[a].qlen == 0) {
@@ -353,6 +342,21 @@ sfq_dequeue(struct Qdisc* sch)
a = q->next[a];
q->allot[a] += q->quantum;
}
+
+ return skb;
+}
+
+static struct sk_buff
+*sfq_dequeue(struct Qdisc* sch)
+{
+ struct sfq_sched_data *q = qdisc_priv(sch);
+ struct sk_buff *skb;
+
+ skb = sfq_q_dequeue(q);
+ if (skb == NULL)
+ return NULL;
+ sch->q.qlen--;
+ sch->qstats.backlog -= skb->len;
return skb;
}
--
1.5.3
^ permalink raw reply related
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