* Re: [PATCH] TCP: removal of unused label
From: Stephen Hemminger @ 2006-06-05 23:02 UTC (permalink / raw)
To: Francois Romieu; +Cc: David S. Miller, netdev
In-Reply-To: <20060605195549.GA14942@electric-eye.fr.zoreil.com>
On Mon, 5 Jun 2006 21:55:49 +0200
Francois Romieu <romieu@fr.zoreil.com> wrote:
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
>
> diff --git a/net/ipv4/tcp_compound.c b/net/ipv4/tcp_compound.c
> index bc54f7e..a3c36c0 100644
> --- a/net/ipv4/tcp_compound.c
> +++ b/net/ipv4/tcp_compound.c
> @@ -401,6 +401,7 @@ static void tcp_compound_cong_avoid(stru
> static void tcp_compound_get_info(struct sock *sk, u32 ext, struct sk_buff *skb)
> {
> const struct compound *ca = inet_csk_ca(sk);
> +
> if (ext & (1 << (INET_DIAG_VEGASINFO - 1))) {
> struct tcpvegas_info *info;
>
> @@ -411,7 +412,6 @@ static void tcp_compound_get_info(struct
> info->tcpv_rttcnt = ca->cntRTT;
> info->tcpv_rtt = ca->baseRTT;
> info->tcpv_minrtt = ca->minRTT;
> - rtattr_failure:;
> }
> }
>
rtattr_failure is used inside __RTA_PUT() macro. It's gross, but there are
those who love it..
^ permalink raw reply
* Re: [PATCH] TCP: removal of unused label
From: David Miller @ 2006-06-05 23:03 UTC (permalink / raw)
To: shemminger; +Cc: romieu, netdev
In-Reply-To: <20060605160240.4951f7ad@dxpl.pdx.osdl.net>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Mon, 5 Jun 2006 16:02:40 -0700
> rtattr_failure is used inside __RTA_PUT() macro. It's gross, but there are
> those who love it..
Yes, it was clear that this patch wasn't build tested.
And GCC usually warns very loudly about truly unused
labels.
^ permalink raw reply
* [PATCH 0/2] e1000: fixes for netpoll+NAPI, ARM
From: Kok, Auke @ 2006-06-05 23:09 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
Hi,
This patch series implements two e1000 fixes:
1: fix netpoll with NAPI
2: fix ARM prefetch failure by removing risky prefetches
These changes are available through git:
git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes
these patches are against
netdev-2.6#upstream-fixes c7812d8ccf1d11f29f752f53727ef6b55bc35150
---
Jeff:
The patch earlier sent regarding:
e1000: fix irq sharing when running ethtool test
is also still in this branch.
They are intended for jgarzik/netdev-2.6#upstream-fixes.
Cheers,
Auke
---
drivers/net/e1000/e1000_main.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply
* [PATCH 1/2] e1000: fix netpoll with NAPI
From: Kok, Auke @ 2006-06-05 23:11 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
In-Reply-To: <20060605230917.12584.55755.stgit@gitlost.site>
Netpoll was broken due to the earlier addition of multiqueue.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000/e1000_main.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index ed15fca..7103a0e 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -4629,10 +4629,17 @@ static void
e1000_netpoll(struct net_device *netdev)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
+#ifdef CONFIG_E1000_NAPI
+ int budget = 0;
+
+ disable_irq(adapter->pdev->irq);
+ e1000_clean_tx_irq(adapter, adapter->tx_ring);
+ adapter->clean_rx(adapter, adapter->rx_ring, &budget, netdev->weight);
+#else
+
disable_irq(adapter->pdev->irq);
e1000_intr(adapter->pdev->irq, netdev, NULL);
e1000_clean_tx_irq(adapter, adapter->tx_ring);
-#ifndef CONFIG_E1000_NAPI
adapter->clean_rx(adapter, adapter->rx_ring);
#endif
enable_irq(adapter->pdev->irq);
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply related
* [PATCH 2/2] e1000: remove risky prefetch on next_skb->data
From: Kok, Auke @ 2006-06-05 23:11 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
In-Reply-To: <20060605230917.12584.55755.stgit@gitlost.site>
It was brought to our attention that the prefetches break e1000 traffic
on xscale/arm architectures. Remove them for now. We'll let them
stay in mm for a while, or find a better solution to enable.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000/e1000_main.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 7103a0e..aef616f 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3519,7 +3519,7 @@ e1000_clean_rx_irq(struct e1000_adapter
buffer_info = &rx_ring->buffer_info[i];
while (rx_desc->status & E1000_RXD_STAT_DD) {
- struct sk_buff *skb, *next_skb;
+ struct sk_buff *skb;
u8 status;
#ifdef CONFIG_E1000_NAPI
if (*work_done >= work_to_do)
@@ -3537,8 +3537,6 @@ e1000_clean_rx_irq(struct e1000_adapter
prefetch(next_rxd);
next_buffer = &rx_ring->buffer_info[i];
- next_skb = next_buffer->skb;
- prefetch(next_skb->data - NET_IP_ALIGN);
cleaned = TRUE;
cleaned_count++;
@@ -3668,7 +3666,7 @@ e1000_clean_rx_irq_ps(struct e1000_adapt
struct e1000_buffer *buffer_info, *next_buffer;
struct e1000_ps_page *ps_page;
struct e1000_ps_page_dma *ps_page_dma;
- struct sk_buff *skb, *next_skb;
+ struct sk_buff *skb;
unsigned int i, j;
uint32_t length, staterr;
int cleaned_count = 0;
@@ -3697,8 +3695,6 @@ e1000_clean_rx_irq_ps(struct e1000_adapt
prefetch(next_rxd);
next_buffer = &rx_ring->buffer_info[i];
- next_skb = next_buffer->skb;
- prefetch(next_skb->data - NET_IP_ALIGN);
cleaned = TRUE;
cleaned_count++;
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply related
* Re: [PATCH 2.6.18 2/3] tg3: Convert to non-LLTX
From: David Miller @ 2006-06-05 23:06 UTC (permalink / raw)
To: shemminger; +Cc: mchan, herbert, jgarzik, netdev
In-Reply-To: <20060605155834.031d37a2@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Mon, 5 Jun 2006 15:58:34 -0700
> Perhaps there is something simpler that could be done with a ring
> model and some atomic primitives like cmpxchg()?
cmpxchg() is something not available natively on many platforms, you
can't even emulate it %100 properly on systems that just have some
kind of test-and-set spinlock type primitive.
You can synchronize the cmpxchg() itself using a spinlock on such
platforms, but you cannot synchronize the accesses done by other
processors which do not use cmpxchg().
So using cmpxchg() would block out such platforms from being able
to use the tg3 driver any longer, which really isn't an option.
^ permalink raw reply
* Re: [PATCH 2.6.18 2/3] tg3: Convert to non-LLTX
From: Michael Chan @ 2006-06-05 21:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, herbert, jgarzik, netdev
In-Reply-To: <20060605155834.031d37a2@localhost.localdomain>
On Mon, 2006-06-05 at 15:58 -0700, Stephen Hemminger wrote:
>
> Since you are going more lockless, you probably need memory barriers.
No, we're not going more lockless. We're simply replacing the private
tx_lock with dev->xmit_lock by dropping the LLTX feature flag. The
amount of locking is exactly the same as before.
^ permalink raw reply
* Re: [PATCH 2/2] e1000: remove risky prefetch on next_skb->data
From: Rick Jones @ 2006-06-05 23:21 UTC (permalink / raw)
To: Kok, Auke; +Cc: Garzik, Jeff, netdev, Brandeburg, Jesse, Kok, Auke
In-Reply-To: <20060605231127.12584.14321.stgit@gitlost.site>
Kok, Auke wrote:
> It was brought to our attention that the prefetches break e1000 traffic
> on xscale/arm architectures. Remove them for now. We'll let them
> stay in mm for a while, or find a better solution to enable.
Out of curiousity, what breaks?
rick jones
^ permalink raw reply
* Re: [patch 06/17] neighbour.c, pneigh_get_next() skips published entry
From: David Miller @ 2006-06-05 23:30 UTC (permalink / raw)
To: akpm; +Cc: netdev, Jari.Takkala
In-Reply-To: <200606020328.k523S8hh028820@shell0.pdx.osdl.net>
From: akpm@osdl.org
Date: Thu, 01 Jun 2006 20:32:26 -0700
> From: "Jari Takkala" <Jari.Takkala@Q9.com>
>
> Fix a problem where output from /proc/net/arp skips a record when the full
> output does not fit into the users read() buffer.
>
> To reproduce: publish a large number of ARP entries (more than 10 required
> on my system). Run 'dd if=/proc/net/arp of=arp-1024.out bs=1024'. View
> the output, one entry will be missing.
>
> Signed-off-by: Jari Takkala <jari.takkala@q9.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
This patch doesn't make any sense, I've been over it a few
times.
The seqfile layer should take care of that user buffering
issue transparently as long as we implement the interface
callbacks properly.
Even if something needs to be fixed in the pneigh dumper,
special casing *pos==1 doesn't look right. Also, if pneigh
has this problem, how come the neigh seqfile iterators don't
have the same problem or do they?
^ permalink raw reply
* Re: MIB "ipInHdrErrors" error
From: David Miller @ 2006-06-05 23:38 UTC (permalink / raw)
To: weid; +Cc: netdev
In-Reply-To: <1148546261.3038.14.camel@RHEL3GM>
From: Wei Dong <weid@nanjing-fnst.com>
Date: Thu, 25 May 2006 16:37:42 +0800
> When I test linux kernel 2.6.9-34, and find that kernel statistics
> about ipInHdrErrors which exsits in file /proc/net/snmp doesn't increase
> correctly. The criteria conform to RFC2011:
>
> ipInHdrErrors OBJECT-TYPE
> SYNTAX Counter32
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The number of input datagrams discarded due to errors in
> their IP headers, including bad checksums, version number
> mismatch, other format errors, time-to-live exceeded, errors
> discovered in processing their IP options, etc."
>
> When kernel receives an IP packet containing error protocol in IP
> header, kernel doesn't increase this counter "ipInHdrErrors".
This event is not listed in the description you quoted.
> Also, when kernel receives an IP packet and need to forward, but
> TTL=1 or TTL=0, kernel just sends an ICMP packet to inform the
> sender TTL count exceeded, and doesn't increase this counter.
This part of your change seems correct, please just resubmit
this part.
^ permalink raw reply
* Re: [PATCH v3] bridge: fix locking and memory leak in br_add_bridge
From: David Miller @ 2006-06-05 23:38 UTC (permalink / raw)
To: shemminger; +Cc: jbenc, netdev
In-Reply-To: <20060527094528.0c330d9f@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Sat, 27 May 2006 09:45:28 -0700
> There are several bugs in error handling in br_add_bridge:
> - when dev_alloc_name fails, allocated net_device is not freed
> - unregister_netdev is called when rtnl lock is held
> - free_netdev is called before netdev_run_todo has a chance to be run after
> unregistering net_device
>
> Signed-off-by: Jiri Benc <jbenc@suse.cz>
> Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Applied, thanks a lot.
^ permalink raw reply
* [PATCH 0/2] PHYLIB: Fix forcing mode reduction
From: Nathaniel Case @ 2006-06-05 23:45 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev, Jeff Garzik, galak
On Mon, 2006-06-05 at 17:08 -0500, Andy Fleming wrote:
> Looks good. Feel free to send these patches to
> netdev@vger.kernel.org (you may need to subscribe), and copy Jeff
> Garzik <jeff@garzik.org>.
This fixes a problem seen when a port without a cable connected would
repeatedly print out "Trying 1000/HALF". While in the PHY_FORCING
state, the call to phy_read_status() was resetting the value of
phydev->speed and phydev->duplex, preventing it from incrementally
trying the speed/duplex variations.
Since we really just want the link status updated for the PHY_FORCING
state, calling genphy_update_link() instead of phy_read_status() fixes
this issue.
Patch tested on a MPC8540 platform with a BCM5421 PHY.
Signed-off-by: Nate Case <ncase@xes-inc.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
---
--- a/drivers/net/phy/phy.c 2006-06-04 16:01:59.000000000 -0500
+++ b/drivers/net/phy/phy.c 2006-06-05 10:55:31.000000000 -0500
@@ -767,7 +783,7 @@
}
break;
case PHY_FORCING:
- err = phy_read_status(phydev);
+ err = genphy_update_link(phydev);
if (err)
break;
--- a/drivers/net/phy/phy_device.c 2006-06-04 16:02:08.000000000 -0500
+++ b/drivers/net/phy/phy_device.c 2006-06-04 19:12:26.000000000 -0500
@@ -417,6 +417,7 @@
return 0;
}
+EXPORT_SYMBOL(genphy_update_link);
/* genphy_read_status
*
^ permalink raw reply
* [PATCH 1/2] PHYLIB: Add get_link ethtool helper function
From: Nathaniel Case @ 2006-06-05 23:48 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev, Jeff Garzik, galak
This adds a phy_ethtool_get_link() function along the same lines as
phy_ethtool_gset(). This provides drivers utilizing PHYLIB an
alternative to using ethtool_op_get_link(). This is more desirable
since the "Link detected" field in ethtool would actually reflect the
state of the PHY register.
Patch depends on previous patch (0/2).
Signed-off-by: Nate Case <ncase@xes-inc.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
---
--- a/drivers/net/phy/phy.c 2006-06-04 16:01:59.000000000 -0500
+++ b/drivers/net/phy/phy.c 2006-06-05 10:55:31.000000000 -0500
@@ -301,6 +301,22 @@
return 0;
}
+/*
+ * phy_ethtool_get_link:
+ * A generic ethtool get_link function which is more accurate than
+ * the network interface carrier status since it queries the
+ * PHY directly.
+ */
+u32 phy_ethtool_get_link(struct phy_device *phydev)
+{
+ int err;
+
+ err = genphy_update_link(phydev);
+ if (err)
+ return 0;
+
+ return (u32) phydev->link;
+}
/* Note that this function is currently incompatible with the
* PHYCONTROL layer. It changes registers without regard to
--- a/include/linux/phy.h 2006-06-05 11:33:59.000000000 -0500
+++ b/include/linux/phy.h 2006-06-04 19:31:51.000000000 -0500
@@ -374,6 +374,7 @@
void phy_stop_machine(struct phy_device *phydev);
int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd);
int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd);
+u32 phy_ethtool_get_link(struct phy_device *phydev);
int phy_mii_ioctl(struct phy_device *phydev,
struct mii_ioctl_data *mii_data, int cmd);
int phy_start_interrupts(struct phy_device *phydev);
^ permalink raw reply
* [PATCH 2/2] PHYLIB/gianfar: Use phy_ethtool_get_link() for get_link op
From: Nathaniel Case @ 2006-06-05 23:48 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev, Jeff Garzik, galak
This patch makes the gianfar ethtool code use phy_ethtool_get_link() instead of
ethtool_op_get_link().
Patch depends on previous one (1/2).
Signed-off-by: Nate Case <ncase@xes-inc.com>
---
--- a/drivers/net/gianfar_ethtool.c 2006-06-05 11:27:19.000000000 -0500
+++ b/drivers/net/gianfar_ethtool.c 2006-06-04 19:31:01.000000000 -0500
@@ -228,6 +228,18 @@
buf[i] = gfar_read(&theregs[i]);
}
+static u32 gfar_get_link(struct net_device *dev)
+{
+ struct gfar_private *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phydev;
+
+ if (NULL == phydev)
+ return -ENODEV;
+
+ return phy_ethtool_get_link(phydev);
+}
+
+
/* Convert microseconds to ethernet clock ticks, which changes
* depending on what speed the controller is running at */
static unsigned int gfar_usecs2ticks(struct gfar_private *priv, unsigned int usecs)
@@ -574,7 +578,7 @@
.get_drvinfo = gfar_gdrvinfo,
.get_regs_len = gfar_reglen,
.get_regs = gfar_get_regs,
- .get_link = ethtool_op_get_link,
+ .get_link = gfar_get_link,
.get_coalesce = gfar_gcoalesce,
.set_coalesce = gfar_scoalesce,
.get_ringparam = gfar_gringparam,
^ permalink raw reply
* Re: [PATCH] TCP changes for 2.6.18
From: David Miller @ 2006-06-05 23:58 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20060605110331.0f058738@dxpl.pdx.osdl.net>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Mon, 5 Jun 2006 11:03:31 -0700
> Dave, please consider adding these for the 2.6.18.
I'll pick these into my tree by extracting out the patches.
Your tree wasn't based upon the net-2.6.18 tree, so if I just
pull it into mine I'll get all the upstream changes since I
cut the net-2.6.18 which at the current time I don't want :)
BTW, it seems we now have at least 3 instances "VEGAS + stuff"
and thus the core vegas logic is duplicated that many times.
Would be nice to have some core vegas infrastructure in the
generic congestion avoidance layer at some point.
^ permalink raw reply
* Re: [PATCH 2/2] e1000: remove risky prefetch on next_skb->data
From: Brandeburg, Jesse @ 2006-06-06 0:12 UTC (permalink / raw)
To: Rick Jones
Cc: Kok, Auke-jan H, Garzik, Jeff, netdev, Brandeburg, Jesse,
Kok, Auke
In-Reply-To: <4484BC62.3090707@hp.com>
On Mon, 5 Jun 2006, Rick Jones wrote:
>
> Kok, Auke wrote:
> > It was brought to our attention that the prefetches break e1000 traffic
> > on xscale/arm architectures. Remove them for now. We'll let them
> > stay in mm for a while, or find a better solution to enable.
>
> Out of curiousity, what breaks?
Hi Rick, according to our reporter, receives break. The prefetch (not
always, but sometimes) lets the processor get junk from the prefetched
area. Apparently this version of arm doesn't quite do as strict
enforcement of bus snoops as x86, ia64, (and even pSeries!) does.
This manifested with a large drop in receive peformance using TCP,
probably because it was retransmitting frequently.
Jesse
^ permalink raw reply
* Re: [PATCH 2/2] e1000: remove risky prefetch on next_skb->data
From: Rick Jones @ 2006-06-06 0:16 UTC (permalink / raw)
To: Brandeburg, Jesse; +Cc: Kok, Auke-jan H, Garzik, Jeff, netdev, Kok, Auke
In-Reply-To: <Pine.WNT.4.63.0606051707520.1168@jbrandeb-desk.amr.corp.intel.com>
Brandeburg, Jesse wrote:
> On Mon, 5 Jun 2006, Rick Jones wrote:
>>Kok, Auke wrote:
>>
>>>It was brought to our attention that the prefetches break e1000 traffic
>>>on xscale/arm architectures. Remove them for now. We'll let them
>>>stay in mm for a while, or find a better solution to enable.
>>
>>Out of curiousity, what breaks?
>
>
> Hi Rick, according to our reporter, receives break. The prefetch (not
> always, but sometimes) lets the processor get junk from the prefetched
> area. Apparently this version of arm doesn't quite do as strict
> enforcement of bus snoops as x86, ia64, (and even pSeries!) does.
Bear with me, I'm a software guy :) I interpret that to mean that the
processor is basically broken? If so, wouldn't it be the case that
prefetch() needs to become a noop on that processor?
> This manifested with a large drop in receive peformance using TCP,
> probably because it was retransmitting frequently.
I forget - what were the gains on the other CPUs?
rick
>
> Jesse
^ permalink raw reply
* Re: [PATCH 2/2] e1000: remove risky prefetch on next_skb->data
From: Andi Kleen @ 2006-06-06 0:22 UTC (permalink / raw)
To: Rick Jones
Cc: Brandeburg, Jesse, Kok, Auke-jan H, Garzik, Jeff, netdev,
Kok, Auke
In-Reply-To: <4484C95B.6010009@hp.com>
> Bear with me, I'm a software guy :) I interpret that to mean that the
> processor is basically broken? If so, wouldn't it be the case that
> prefetch() needs to become a noop on that processor?
I would agree with Rick - if prefetch() is broken on Xscale it should be disabled
in the architecture, not in individual drivers. Otherwise all other code
that use it might be broken too.
Maybe it's only broken on MMIO and not normal memory - in that
case introducing a mmio_prefetch() (and defining it as an nop on Xscale) would be also
an option.
-Andi
^ permalink raw reply
* Re: [PATCH 2/2] e1000: remove risky prefetch on next_skb->data
From: Brandeburg, Jesse @ 2006-06-06 0:26 UTC (permalink / raw)
To: Rick Jones
Cc: Brandeburg, Jesse, Kok, Auke-jan H, Garzik, Jeff, netdev,
Kok, Auke
In-Reply-To: <4484C95B.6010009@hp.com>
On Mon, 5 Jun 2006, Rick Jones wrote:
> Brandeburg, Jesse wrote:
> > Hi Rick, according to our reporter, receives break. The prefetch (not
> > always, but sometimes) lets the processor get junk from the prefetched
> > area. Apparently this version of arm doesn't quite do as strict
> > enforcement of bus snoops as x86, ia64, (and even pSeries!) does.
>
> Bear with me, I'm a software guy :) I interpret that to mean that the
> processor is basically broken? If so, wouldn't it be the case that
> prefetch() needs to become a noop on that processor?
For a software guy, you're making a large leap :-) I wouldn't say the
processor is broken, it is more sensitive to our (admittedly) bad behavior
when prefetching data for one descriptor *past* any that we currently
*know* are done. ARM/XSCALE is able to use prefetch all over the place in
its arch specific code with no problems (i'm relying on advice from
someone else on this, i haven't validated with mine own eyes)
Someone else had complained about this particular prefetch anyway (and it
was the most speculative with the least amount of gain) on the list
before, so given this information we're trying to take the conservative
route.
This patch was tested by the reporter and he was pleased with the result.
> > This manifested with a large drop in receive peformance using TCP,
> > probably because it was retransmitting frequently.
>
> I forget - what were the gains on the other CPUs?
One system (from a while back) I have numbers for showed a 10% increase in
packets per second that could be handled using netperf udp receive, with
the prefetch code in place.
And to Andi's make that came in while I was typing this, I reiterate I do
not believe ARM/XSCALE prefetch to be broken.
Jesse
^ permalink raw reply
* Re: [PATCH 2.6.18 2/3] tg3: Convert to non-LLTX
From: Stephen Hemminger @ 2006-06-06 0:31 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, herbert, jgarzik, netdev
In-Reply-To: <1149542985.13155.11.camel@rh4>
On Mon, 05 Jun 2006 14:29:45 -0700
"Michael Chan" <mchan@broadcom.com> wrote:
> On Mon, 2006-06-05 at 15:58 -0700, Stephen Hemminger wrote:
>
> >
> > Since you are going more lockless, you probably need memory barriers.
>
> No, we're not going more lockless. We're simply replacing the private
> tx_lock with dev->xmit_lock by dropping the LLTX feature flag. The
> amount of locking is exactly the same as before.
Those spin lock's were also acting as barriers.
Are you sure code is safe in the face of cpu reordering.
--
If one would give me six lines written by the hand of the most honest
man, I would find something in them to have him hanged. -- Cardinal Richlieu
^ permalink raw reply
* Re: [PATCH 2.6.18 2/3] tg3: Convert to non-LLTX
From: Michael Chan @ 2006-06-05 23:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, herbert, jgarzik, netdev
In-Reply-To: <20060605173159.33d81d59@localhost.localdomain>
On Mon, 2006-06-05 at 17:31 -0700, Stephen Hemminger wrote:
> On Mon, 05 Jun 2006 14:29:45 -0700
> "Michael Chan" <mchan@broadcom.com> wrote:
>
> > On Mon, 2006-06-05 at 15:58 -0700, Stephen Hemminger wrote:
> >
> > >
> > > Since you are going more lockless, you probably need memory barriers.
> >
> > No, we're not going more lockless. We're simply replacing the private
> > tx_lock with dev->xmit_lock by dropping the LLTX feature flag. The
> > amount of locking is exactly the same as before.
>
> Those spin lock's were also acting as barriers.
Why is it different whether we use dev->xmit_lock right before entering
hard_start_xmit() without LLTX or a private tx_lock at the beginning of
hard_start_xmit() with LLTX? In both cases, we take one BH disabling
lock to serialize hard_start_xmit(). And in both cases, the spinlock
will provide the same barrier effect.
> Are you sure code is safe in the face of cpu reordering.
>
Yes, hard_start_xmit() only touches the tx producer index and tx
completion handling only touches the tx consumer index.
There is actually one wrinkle but it has nothing to do with the locking
change in this patch. During the sequence of writing the tx descriptors
to memory and the MMIO write to tell the chip to DMA the new
descriptors, the MMIO can be re-ordered ahead of the writing of the tx
descriptors on the powerpc, for example. This will lead to DMAing stale
descriptor data. In earlier kernels, the ppc writel has a memory barrier
to prevent this but it was removed in recent kernels. We had a
discussion with Anton Blanchard and other folks at IBM and DaveM on this
and it was decided that the writel should provide the barrier instead of
drivers adding all kinds of barriers throughout the driver code.
^ permalink raw reply
* Re: [PATCH 2/3] pci: bcm43xx avoid pci_find_device
From: Jeff Garzik @ 2006-06-06 1:18 UTC (permalink / raw)
To: Greg KH
Cc: Jiri Slaby, Greg KH, Linux Kernel Mailing List, linux-pci,
jgarzik, netdev, mb, st3, linville
In-Reply-To: <20060605205309.GA31061@kroah.com>
On Mon, Jun 05, 2006 at 01:53:09PM -0700, Greg KH wrote:
> Why not just use the proper pci interface? Why poke around in another
> pci device to steal an irq, when that irq might not even be valid?
> (irqs are not valid until pci_enable_device() is called on them...)
Answered this question the last time you asked.
Answer: this is an embedded platform that needs such poking. The
wireless device is _another_ device.
Jeff
^ permalink raw reply
* Re: [PATCH 2.6.18 1/3] tg3: Remove unnecessary tx_lock
From: Herbert Xu @ 2006-06-06 2:04 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, jgarzik, netdev
In-Reply-To: <1149536843.13155.6.camel@rh4>
On Mon, Jun 05, 2006 at 12:47:23PM -0700, Michael Chan wrote:
> Remove tx_lock where it is unnecessary. tg3 runs lockless and so it
> requires interrupts to be disabled and sync'ed, netif_queue and NAPI
> poll to be stopped before the device can be reconfigured. After
> stopping everything, it is no longer necessary to get the tx_lock.
The paths where full lock is preceded by netif_tx_disable are obviously
safe (well, once you take off the LLTX flag anyway). However, there are
paths that don't do netif_tx_disable (e.g., tg3_set_rx_mode), are they
safe as well?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] hush noisy ieee80211 CCMP printks
From: Jouni Malinen @ 2006-06-06 3:41 UTC (permalink / raw)
To: Jason Lunz; +Cc: linville, netdev
In-Reply-To: <20060605160335.GB25688@knob.reflex>
On Mon, Jun 05, 2006 at 12:03:35PM -0400, Jason Lunz wrote:
> If these are a real problem, I'll gladly help debug it. I'm using
> 2.6.17-rc5's bcm43xx and the in-kernel ieee80211 softmac stack. I'm
> using wpa/ccmp/aes with an openwrt AP.
Do you happen to have a wireless sniffer that you could use to capture
the frames? It would be interesting to see whether such a capture log
could be mapped into the dropped frames shown in the kernel debug log.
> > In many cases, this may be caused by something missing in local
> > filtering (e.g., retry duplicates are not filtered out correctly or
> > messages to incorrect addresses are allowed through, etc.).
>
> Is it the driver's responsibility to do this filtering, or the softmac
> stack's? Can you show me a code example where this filtering is done
> properly?
This is generic functionality and something I would like to see
implemented in the 802.11 stack so that every low-level driver would not
need to do this. I don't remember what net/ieee80211 code does in this
area. Devicescape code (net/d80211 in wireless-dev.git) has duplicate
detection in ieee80211_rx_h_check().
> I can try different implementations of WPA in the AP if necessary. I
> think openwrt has other options. My end is in-kernel ieee80211_softmac -
> is there anything you'd like me to look at there?
Would you be interested in testing this with net/d80211 code and
wireless-dev.git? It would be interesting to see whether you would get a
different result with the AP end kept in identical configuration and
just changing the client side 802.11 network stack. With net/d80211, the
CCMP replay detection printk is disabled by default (which is what
should be done with net/ieee80211 implementation, too), so that needs to
be enabled at build time. Counters are available from procfs files,
though, so number of replays can be compared.
> If the messages are actually useful, and unusual, then they should
> probably stay. But I get a LOT of them, and my wireless is working just
> fine.
Unfortunately, they are not really unusual. They are useful--at least
for developers--so #ifdef or run-time option for enabling/disabling them
would be nice.
> I noticed that there are counters being incremented where those printks
> are. How do I see those counters from userspace?
These used to be visible from procfs in the original implementation in
Host AP driver. However, it looks like print_stats function is not
called at all in the version that is in net/ieee80211, so the counters
may not be exposed at the moment. They should be, though..
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH] Fixup struct ip_mc_list::multiaddr type
From: David Miller @ 2006-06-06 4:04 UTC (permalink / raw)
To: adobriyan; +Cc: netdev
In-Reply-To: <20060526193009.GB7266@martell.zuzino.mipt.ru>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Fri, 26 May 2006 23:30:09 +0400
> All users except two expect 32-bit big-endian value. One is of
>
> ->multiaddr = ->multiaddr
>
> variety. And last one is "%08lX".
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied, thanks Alexey.
^ 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