* Re: e1000 tcp checksum incorrect, x86 64b
From: Jon Smirl @ 2007-09-28 17:39 UTC (permalink / raw)
To: Rick Jones; +Cc: Herbert Xu, netdev
In-Reply-To: <46FD2D3B.4050605@hp.com>
On 9/28/07, Rick Jones <rick.jones2@hp.com> wrote:
> Herbert Xu wrote:
> > Jon Smirl <jonsmirl@gmail.com> wrote:
> >
> >>App is writing seven bytes to the socket. Socket write timeout expires
> >>and the seven bytes are sent. The checksum is not getting inserted
> >>into the packet. It is set to a constant 0x8389 instead of the right
> >>value. App is gmpc 0.15.4.95, Revision: 6794
> >>
> >>Attached Wireshark packet trace show the problem. e1000 is 192.168.1.4
> >>64bit, Q6600. Dell Dimension 9200
> >
> >
> > Wireshark is broken. It needs to know TP_STATUS_CSUMNOTREADY
> > means that the checksum is partial and will only be completed
> > when the hardware sends the packet out.
> >
> > Alternatively disable checksum offload with ethtool.
>
> Or take the packet traces "outboard" of the NIC somewhere/somehow.
>
> What problem(s) led to your taking the packet trace in the first place?
I was working on the Ethernet driver for another embedded system
attached to the box. I noticed these errors going to my NSLU2 which I
thought was working ok. But now I know they are not real errors.
Ethernet driver for MPC5200 in embedded system still has some
problems. It is being discussed on linuxppc-embedded.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: UDP Out 0f Sequence
From: Randy Macleod @ 2007-09-28 17:22 UTC (permalink / raw)
To: Majumder, Rajib; +Cc: Rick Jones, 'David Miller', netdev
In-Reply-To: <4512C10A.4070303@hp.com>
Rick Jones wrote:
> Majumder, Rajib wrote:
>> Let's say we have 2 uniprocessor hosts connected back to back. Is
>> there any possibility of an out-of-order scenario on recv?
>
> Your application should be written on the assumption that it is
> possible, regardless of the specifics of the hosts involved, however
> unlikely they may be to reorder traffic.
>
> > Is this same for all kernel (linux/solaris)?
>
> Your application should be written on the assumtion that it is possible,
> regardless of the specifics of the OSes involved, however unlikely they
> may be to reorder traffic.
Or you should use a different protocol stack that guarantees order.
Have you considered TCP, DCCP or even TIPC?
The solution depends on your application requirements and your
projects tolerance for risk.
// Randy
^ permalink raw reply
* MSI interrupts and disable_irq
From: Ayaz Abdulla @ 2007-09-27 20:42 UTC (permalink / raw)
To: Jeff Garzik, Manfred Spraul, nedev
I am trying to track down a forcedeth driver issue described by bug 9047
in bugzilla (2.6.23-rc7-git1 forcedeth w/ MCP55 oops under heavy load).
I added a patch to synchronize the timer handlers so that one handler
doesn't accidently enable the IRQ while another timer handler is running
(see attachment 'Add timer lock' in bug report) and for other processing
protection.
However, the system still had an Oops. So I added a lock around the
nv_rx_process_optimized() and the Oops has not happened (see attachment
'New patch for locking' in bug report). This would imply a
synchronization issue. However, the only callers of that function are
the IRQ handler and the timer handlers (in non-NAPI case). The timer
handlers use disable_irq so that the IRQ handler does not contend with
them. It looks as if disable_irq is not working properly.
This issue repros only with MSI interrupt and not legacy INTx
interrupts. Any ideas?
Thanks,
Ayaz
^ permalink raw reply
* Re: 2.6.23-rc8: cannot make netconsole work
From: Andrey Borzenkov @ 2007-09-28 18:16 UTC (permalink / raw)
To: Matt Mackall; +Cc: netdev, linux-kernel
In-Reply-To: <20070928153253.GV19691@waste.org>
[-- Attachment #1: Type: text/plain, Size: 689 bytes --]
On Friday 28 September 2007, Matt Mackall wrote:
> On Fri, Sep 28, 2007 at 01:27:55PM +0400, Andrey Borzenkov wrote:
[...]
> > sudo modprobe netconsole netconsole=@/eth0,@/
> >
[...]
> What is your console log level set to? If the messages don't come out
> on the local console, they won't get sent out the network either.
> Fedora at least defaults to hiding most messages. Adding 'debug' to
> your kernel command line will change that.
Well, that was one thing; but for whatever reason it would refuse to work
without explicit MAC of recipient. Adding it made it (but it was of no help
to my original issue ... well, that is another story ...)
Thank you
-andrey
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH]: Second preliminary release of Sun Neptune driver
From: Matheos Worku @ 2007-09-28 18:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ariel.Hendel, Greg.Onufer, jeff, Ashley.Saulsbury
In-Reply-To: <20070927.220027.31653674.davem@davemloft.net>
David Miller wrote:
> Ok, this is rev2, changes:
>
> 1) Jumbo MTU support is now present. I got stuck on this for
> a while because I didn't realize that resetting the RX
> XMAC would reset the XMAC_MAX register. I thought that
> was a TX XMAC resource, ho hum...
>
> Fix this by re-initializing the TX MAC after resetting
> the RX MAC.
>
> 2) Implementing support for jumbograms required a re-examination of
> how TX queue handling was done.
>
> Neptune can report the TX Head at a location which is in the middle
> of a packet's group of descriptors for a multi segment packet.
> Working around this would just overly complicate the code.
>
> We don't need to use the TX Head register. Instead, track the
> "pkt_cnt" field of the TX_CS register. The difference since the
> last reading is the number of full TX frames we can reclaim from
> the ring.
>
> This is not only simpler, it allows us to only need one MMIO
> access (for TX_CS) during a reclaim run instead of two (TX_CS
> and TX_RING_HDL).
>
> A side note, I'm purposefully not using TX mailbox support. It's
> broken in Neptune. If you get the registers in the DMA mailbox, MK
> and MMK are always both set in the TX_CS register. So even if you
> write the MK and MB bits back to TX_CS to clear the interrupt, the
> MMK propagates to MK and you thus get another interrupt. This
> basically makes TX DMA mailbox support useless.
>
> 4) All register write accessors are now of the form xxx(reg, val)
> instead of xxx(val, reg)
>
> 5) Kill PCI_DEVICE_ID_SUN_NEPTUNE define, unneeded.
>
> Performance isn't the best, but the driver is reasonably solid. After
> I flesh out the remaining features that need to be implemented I'll
> take a closer look at that.
>
> Enjoy.
>
> commit 684a7c25fff607dc647f065761bb381f28bddbdb
> Author: David S. Miller <davem@sunset.davemloft.net>
> Date: Thu Sep 27 21:43:57 2007 -0700
>
> [NIU]: Add Sun Neptune ethernet driver.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 467532c..3c94c8f 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2601,6 +2601,13 @@ config NETXEN_NIC
> help
> This enables the support for NetXen's Gigabit Ethernet card.
>
> +config NIU
> + tristate "Sun Neptune 10Gbit Ethernet support"
> + depends on PCI
> + help
> + This enables support for cards based upon Sun's
> + Neptune chipset.
> +
> config PASEMI_MAC
> tristate "PA Semi 1/10Gbit MAC"
> depends on PPC64 && PCI
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 6220c50..cce379b 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -242,3 +242,4 @@ obj-$(CONFIG_NETCONSOLE) += netconsole.o
> obj-$(CONFIG_FS_ENET) += fs_enet/
>
> obj-$(CONFIG_NETXEN_NIC) += netxen/
> +obj-$(CONFIG_NIU) += niu.o
> diff --git a/drivers/net/niu.c b/drivers/net/niu.c
> new file mode 100644
> index 0000000..5b89559
> --- /dev/null
> +++ b/drivers/net/niu.c
>
Dave,
Couple of comments on Jumbo support
TX Side:
Can we rule of fragment size > MAX_TX_DESC_LEN? If that is not the case,
then the frags my need the same tx post and reclaim logic as the skb->data
RX Side
Since the MAC is set not to strip FCS bytes, the last page could
contain just 1 - 4 bytes of FCS. Not only this wastes the page but may
result on bug RX process where skb->len is wrong and a page with junk is
passed to the stack. In our off-the-tree driver, we check this condition
and repost the last page back to the rbr, if it contains just the FCS bytes.
Regards,
Matheos
^ permalink raw reply
* [RFC/PATCH 0/3] UDP memory usage accounting(take 2)
From: Satoshi OSHIMA @ 2007-09-28 13:36 UTC (permalink / raw)
To: Andi Kleen, Evgeniy Polyakov, netdev
Cc: 吉藤 英明, Yumiko SUGITA,
"青木@RedHat"
This patch set try to introduce memory usage accounting for
UDP(currently ipv4 only).
3 points are improved along with some feedback.
(a) to improve scalability, avoiding atomic_*()s as small as
possible
(b) avoiding UDP specific code in IP layer
(c) supporting socket destruction accounting
To implement (b), there is a side effect which affects
accounting on TCP socket. If you find the good solution
to avoid this side effect, please let me know.
Unfortunately, I don't have any NIC with UFO.
So this patch set is not tested with UFO supported
device.
This patch set is for 2.6.23-rc8.
I appreciate your comment/test/feedback.
Satoshi Oshima
^ permalink raw reply
* 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
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