* [BUG?] possible bug in user_enable_block_step()
From: Chris Friesen @ 2013-04-11 22:38 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm looking at user_enable_block_step() in current kernels and it has
the following:
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
task->thread.dbcr0 &= ~DBCR0_IC;
task->thread.dbcr0 = DBCR0_IDM | DBCR0_BT;
regs->msr |= MSR_DE;
Should it be as follows?
task->thread.dbcr0 |= DBCR0_IDM | DBCR0_BT;
If not, then what's the point of clearing the DBCR0_IC bit in the
previous line?
Chris
--
Chris Friesen
Software Designer
500 Palladium Drive, Suite 2100
Ottawa, Ontario K2N 1C2, Canada
www.genband.com
office:+1.343.883.2717
chris.friesen@genband.com
^ permalink raw reply
* Re: [PATCH 1/9] powerpc,kvm: fix imbalance srcu_read_[un]lock()
From: Paul E. McKenney @ 2013-04-11 21:51 UTC (permalink / raw)
To: Paul Mackerras
Cc: Lai Jiangshan, Gleb Natapov, Marcelo Tosatti, Alexander Graf,
kvm-ppc, linux-kernel, kvm, Andrew Morton, linuxppc-dev
In-Reply-To: <20130317212648.GA4259@iris.ozlabs.ibm.com>
On Mon, Mar 18, 2013 at 08:26:48AM +1100, Paul Mackerras wrote:
> On Sat, Mar 16, 2013 at 12:50:49AM +0800, Lai Jiangshan wrote:
> > At the point of up_out label in kvmppc_hv_setup_htab_rma(),
> > srcu read lock is still held.
> >
> > We have to release it before return.
> >
> > Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> > Cc: Marcelo Tosatti <mtosatti@redhat.com>
> > Cc: Gleb Natapov <gleb@redhat.com>
> > Cc: Alexander Graf <agraf@suse.de>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Paul Mackerras <paulus@samba.org>
> > Cc: kvm@vger.kernel.org
> > Cc: kvm-ppc@vger.kernel.org
> > ---
> > arch/powerpc/kvm/book3s_hv.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> > index 80dcc53..c26740e 100644
> > --- a/arch/powerpc/kvm/book3s_hv.c
> > +++ b/arch/powerpc/kvm/book3s_hv.c
> > @@ -1799,7 +1799,7 @@ static int kvmppc_hv_setup_htab_rma(struct kvm_vcpu *vcpu)
> >
> > up_out:
> > up_read(¤t->mm->mmap_sem);
> > - goto out;
> > + goto out_srcu;
>
> Acked-by: Paul Mackerras <paulus@samba.org>
Thank you both, queued for 3.11 (assuming no one has beat me to it).
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 0/2] enable the coreint for the mpc85xx 64bit boards
From: Scott Wood @ 2013-04-11 20:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: Wood Scott-B07421, Kevin Hao, linuxppc
In-Reply-To: <6DEE94C2-19EB-487D-99B5-58789C9230BF@kernel.crashing.org>
On 04/11/2013 08:21:24 AM, Kumar Gala wrote:
>=20
> On Apr 10, 2013, at 8:32 PM, Kevin Hao wrote:
>=20
> > Hi,
> >
> > With the rework of the lazy EE, it seems that 64bit kernel works =20
> pretty
> > well on mpc85xx 64bit boards with lazy EE enabled. So this patch =20
> series
> > tries to enable the coreint for these boards by default. This passed
> > the ltp test on a t4240qds board and is based on Kumar's next =20
> branch.
> >
> > ---
> > Kevin Hao (2):
> > powerpc/irq: remove the unneeded flag PACA_IRQ_EE_EDGE
> > powerpc/85xx: enable coreint for all the 64bit boards
> >
> > arch/powerpc/include/asm/hw_irq.h | 1 -
> > arch/powerpc/kernel/exceptions-64e.S | 1 -
> > arch/powerpc/kernel/irq.c | 8 --------
> > arch/powerpc/platforms/85xx/p5020_ds.c | 5 -----
> > arch/powerpc/platforms/85xx/p5040_ds.c | 5 -----
> > arch/powerpc/platforms/85xx/t4240_qds.c | 5 -----
> > 6 files changed, 25 deletions(-)
>=20
> Scott,
>=20
> I'd appreciate your review and ack on this change.
ACK
-Scott=
^ permalink raw reply
* Re: [PATCH 9/9] powerpc: cpufreq: move cpufreq driver to drivers/cpufreq
From: Rafael J. Wysocki @ 2013-04-11 20:33 UTC (permalink / raw)
To: Viresh Kumar
Cc: robin.randhawa, linux-pm, Liviu.Dudau, linux-kernel, cpufreq,
Steve.Bannister, Paul Mackerras, Olof Johansson, Arnd Bergmann,
arvind.chauhan, linuxppc-dev, linaro-kernel, charles.garcia-tobin
In-Reply-To: <CAKohpomHFgMBAHax=jC_LNd8Gay9aWja+64An7QxnNpaPuuSQQ@mail.gmail.com>
On Thursday, April 11, 2013 12:32:50 PM Viresh Kumar wrote:
> On 11 April 2013 12:29, Olof Johansson <olof@lixom.net> wrote:
> > That's not very nice this late in the staging cycle. Give the powerpc
> > guys a little more time than a single day to come back with test results,
> > please.
>
> Yes we are waiting indefinitely for an Ack from powerpc guys.. If we can
> get a Ack soon, we will get it in 3.10 otherwise next cycle.
Well, I'll be traveling from Saturday morning onwards until the end of the
next week and my window for taking stuff into v3.10 closes in 16 hours.
Whatever is not ready (i.e. ACKed in this particular case) before that time,
won't be taken.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: David Miller @ 2013-04-11 20:22 UTC (permalink / raw)
To: sebastian.hesselbarth
Cc: andrew, jason, linux-kernel, smoch, paulus, linux-arm-kernel,
dale, netdev, linuxppc-dev, florian, buytenh
In-Reply-To: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Date: Thu, 11 Apr 2013 14:40:23 +0200
> This patch adds GRO support to mv643xx_eth by making it invoke
> napi_gro_receive instead of netif_receive_skb.
>
> Signed-off-by: Soeren Moch <smoch@web.de>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] net: mv643xx_eth: use managed clk and allocation
From: David Miller @ 2013-04-11 20:20 UTC (permalink / raw)
To: sebastian.hesselbarth
Cc: andrew, jason, sergei.shtylyov, linux-doc, devicetree-discuss,
linux-kernel, rob.herring, paulus, rob, netdev, linuxppc-dev,
florian, buytenh
In-Reply-To: <1365672574-31123-1-git-send-email-sebastian.hesselbarth@gmail.com>
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Date: Thu, 11 Apr 2013 11:29:32 +0200
> With introduction of common clock framework and the ability to provide
> gated clocks, mv643xx_eth required calls to get and enable these clock
> gates on some platforms. Back then, common clock framework api wasn't
> safe for architectures without support for common clocks. This has
> changed now and there are also managed (devm_) counterparts for clock
> related functions.
>
> The second patch in this series, also converts kzalloc to devm_kzalloc
> where applicable.
>
> Both patches have been sent to the corresponding mailing lists as
> individual patches before. To get the order required to apply them right,
> this patch set combines both patches into one set.
Both applied to net-next, thanks.
^ permalink raw reply
* Re: recommended method of netbooting kernel/dtb in u-boot?
From: Chris Friesen @ 2013-04-11 19:59 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev
In-Reply-To: <20130411195019.GA31025@ovro.caltech.edu>
On 04/11/2013 01:50 PM, Ira W. Snyder wrote:
> I use a hardware setup which sounds similar to yours. The DHCP server
> controls which file is sent to each card.
>
> I use the FIT image format to combine a kernel, dtb, and initrd in one
> package.
>
> <snip>
>
> I used the U-Boot doc/uImage.FIT/*.its examples to get started, and
> wrote my own custom .its file for my board. I don't use anything other
> than the vmlinux.bin.gz provided by the kernel build.
Okay, that's a good data point, thanks.
Chris
^ permalink raw reply
* Re: recommended method of netbooting kernel/dtb in u-boot?
From: Ira W. Snyder @ 2013-04-11 19:50 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev
In-Reply-To: <51670344.2090101@genband.com>
On Thu, Apr 11, 2013 at 12:39:00PM -0600, Chris Friesen wrote:
> On 04/11/2013 12:12 PM, Kumar Gala wrote:
> >
> > On Apr 11, 2013, at 10:44 AM, Chris Friesen wrote:
> >
> >>
> >> Hi all,
> >>
> >> We've got a powerpc system that uses u-boot. In our environment on
> >> bootup u-boot does a DHCP to get networking info, then uses TFTP to
> >> get the kernel, which then does DHCP again and NFS-mounts the
> >> initial root filesystem.
> >>
> >> What's the standard practice for this sort of thing when using
> >> device tree blobs? Do most people use multi-file images or do they
> >> TFTP scripts to load and execute separate kernel/dtb files?
> >
> > We've normally just done multiple tftp fetches and one grabs dtb and
> > one grabs kernel.
>
> Do you hardcode the path to the file in the firmware? Or do you upload
> a script that knows the path to the file?
>
> In our case the path to the boot file(s) depends on which slot the card
> being booted has been inserted in. The DHCP server knows what the path
> is, so it can set dhcpd.conf appropriately, but we need to get that
> information to the firmware on the card being booted.
>
Hello Chris,
I use a hardware setup which sounds similar to yours. The DHCP server
controls which file is sent to each card.
I use the FIT image format to combine a kernel, dtb, and initrd in one
package. Then the U-Boot command "dhcp $address" sets up the network and
tftp's the filename sent by the DHCP server. You don't need to invoke
the U-Boot command "tftp" if you only have one image. "dhcp" is enough.
I used the U-Boot doc/uImage.FIT/*.its examples to get started, and
wrote my own custom .its file for my board. I don't use anything other
than the vmlinux.bin.gz provided by the kernel build.
Hope it helps,
Ira
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: remove deprecated inet_lro support
From: Sebastian Hesselbarth @ 2013-04-11 19:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
Ben Hutchings, netdev, linuxppc-dev, Florian Fainelli,
Lennert Buytenhek, Willy Tarreau
In-Reply-To: <1365709617.3887.185.camel@edumazet-glaptop>
On 04/11/2013 09:46 PM, Eric Dumazet wrote:
> On Thu, 2013-04-11 at 21:11 +0200, Sebastian Hesselbarth wrote:
>> With recent support for GRO, there is no need to keep both LRO and
>> GRO. This patch therefore removes the deprecated inet_lro support
>> from mv643xx_eth. This is work is based on an experimental patch
>> provided by Eric Dumazet and Willy Tarreau.
>>
>> Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth@gmail.com>
>> Based-on-patch-by: Eric Dumazet<eric.dumazet@gmail.com>
>> Based-on-patch-by: Willy Tarreau<w@1wt.eu>
>> ---
>> Note: This patch is based upon recent cleanup patches and GRO support
>> patch for mv643xx_eth.
>>
>> Cc: "David S. Miller"<davem@davemloft.net>
>> Cc: Lennert Buytenhek<buytenh@wantstofly.org>
>> Cc: Andrew Lunn<andrew@lunn.ch>
>> Cc: Jason Cooper<jason@lakedaemon.net>
>> Cc: Florian Fainelli<florian@openwrt.org>
>> Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
>> Cc: Paul Mackerras<paulus@samba.org>
>> Cc: Dale Farnsworth<dale@farnsworth.org>
>> Cc: Ben Hutchings<bhutchings@solarflare.com>
>> Cc: Soeren Moch<smoch@web.de>
>> Cc: Eric Dumazet<eric.dumazet@gmail.com>
>> Cc: Willy Tarreau<w@1wt.eu>
>> Cc: netdev@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>> drivers/net/ethernet/marvell/mv643xx_eth.c | 97 +---------------------------
>> 1 file changed, 3 insertions(+), 94 deletions(-)
>
> Seems fine to me, but you also could remove "select INET_LRO"
> from drivers/net/ethernet/marvell/Kconfig
Ok, I will wait for tomorrow to see if there are more objections and
respin a v2.
Sebastian
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: remove deprecated inet_lro support
From: Eric Dumazet @ 2013-04-11 19:46 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
Ben Hutchings, netdev, linuxppc-dev, Florian Fainelli,
Lennert Buytenhek, Willy Tarreau
In-Reply-To: <1365707488-28819-1-git-send-email-sebastian.hesselbarth@gmail.com>
On Thu, 2013-04-11 at 21:11 +0200, Sebastian Hesselbarth wrote:
> With recent support for GRO, there is no need to keep both LRO and
> GRO. This patch therefore removes the deprecated inet_lro support
> from mv643xx_eth. This is work is based on an experimental patch
> provided by Eric Dumazet and Willy Tarreau.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Based-on-patch-by: Eric Dumazet <eric.dumazet@gmail.com>
> Based-on-patch-by: Willy Tarreau <w@1wt.eu>
> ---
> Note: This patch is based upon recent cleanup patches and GRO support
> patch for mv643xx_eth.
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Lennert Buytenhek <buytenh@wantstofly.org>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Florian Fainelli <florian@openwrt.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Dale Farnsworth <dale@farnsworth.org>
> Cc: Ben Hutchings <bhutchings@solarflare.com>
> Cc: Soeren Moch <smoch@web.de>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Willy Tarreau <w@1wt.eu>
> Cc: netdev@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/net/ethernet/marvell/mv643xx_eth.c | 97 +---------------------------
> 1 file changed, 3 insertions(+), 94 deletions(-)
Seems fine to me, but you also could remove "select INET_LRO"
from drivers/net/ethernet/marvell/Kconfig
^ permalink raw reply
* [PATCH] net: mv643xx_eth: remove deprecated inet_lro support
From: Sebastian Hesselbarth @ 2013-04-11 19:11 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, Eric Dumazet, linux-kernel,
David S. Miller, Soeren Moch, Paul Mackerras, linux-arm-kernel,
Dale Farnsworth, Ben Hutchings, netdev, linuxppc-dev,
Florian Fainelli, Lennert Buytenhek, Willy Tarreau
With recent support for GRO, there is no need to keep both LRO and
GRO. This patch therefore removes the deprecated inet_lro support
from mv643xx_eth. This is work is based on an experimental patch
provided by Eric Dumazet and Willy Tarreau.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Based-on-patch-by: Eric Dumazet <eric.dumazet@gmail.com>
Based-on-patch-by: Willy Tarreau <w@1wt.eu>
---
Note: This patch is based upon recent cleanup patches and GRO support
patch for mv643xx_eth.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Florian Fainelli <florian@openwrt.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Dale Farnsworth <dale@farnsworth.org>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Cc: Soeren Moch <smoch@web.de>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 97 +---------------------------
1 file changed, 3 insertions(+), 94 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index c850d04..d0afeea 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -56,8 +56,8 @@
#include <linux/phy.h>
#include <linux/mv643xx_eth.h>
#include <linux/io.h>
+#include <linux/interrupt.h>
#include <linux/types.h>
-#include <linux/inet_lro.h>
#include <linux/slab.h>
#include <linux/clk.h>
@@ -316,12 +316,6 @@ struct mib_counters {
u32 rx_overrun;
};
-struct lro_counters {
- u32 lro_aggregated;
- u32 lro_flushed;
- u32 lro_no_desc;
-};
-
struct rx_queue {
int index;
@@ -335,9 +329,6 @@ struct rx_queue {
dma_addr_t rx_desc_dma;
int rx_desc_area_size;
struct sk_buff **rx_skb;
-
- struct net_lro_mgr lro_mgr;
- struct net_lro_desc lro_arr[8];
};
struct tx_queue {
@@ -373,8 +364,6 @@ struct mv643xx_eth_private {
spinlock_t mib_counters_lock;
struct mib_counters mib_counters;
- struct lro_counters lro_counters;
-
struct work_struct tx_timeout_task;
struct napi_struct napi;
@@ -503,42 +492,12 @@ static void txq_maybe_wake(struct tx_queue *txq)
}
}
-
-/* rx napi ******************************************************************/
-static int
-mv643xx_get_skb_header(struct sk_buff *skb, void **iphdr, void **tcph,
- u64 *hdr_flags, void *priv)
-{
- unsigned long cmd_sts = (unsigned long)priv;
-
- /*
- * Make sure that this packet is Ethernet II, is not VLAN
- * tagged, is IPv4, has a valid IP header, and is TCP.
- */
- if ((cmd_sts & (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
- RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_MASK |
- RX_PKT_IS_VLAN_TAGGED)) !=
- (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
- RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_TCP_IPV4))
- return -1;
-
- skb_reset_network_header(skb);
- skb_set_transport_header(skb, ip_hdrlen(skb));
- *iphdr = ip_hdr(skb);
- *tcph = tcp_hdr(skb);
- *hdr_flags = LRO_IPV4 | LRO_TCP;
-
- return 0;
-}
-
static int rxq_process(struct rx_queue *rxq, int budget)
{
struct mv643xx_eth_private *mp = rxq_to_mp(rxq);
struct net_device_stats *stats = &mp->dev->stats;
- int lro_flush_needed;
int rx;
- lro_flush_needed = 0;
rx = 0;
while (rx < budget && rxq->rx_desc_count) {
struct rx_desc *rx_desc;
@@ -599,12 +558,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->protocol = eth_type_trans(skb, mp->dev);
- if (skb->dev->features & NETIF_F_LRO &&
- skb->ip_summed == CHECKSUM_UNNECESSARY) {
- lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
- lro_flush_needed = 1;
- } else
- napi_gro_receive(&mp->napi, skb);
+ napi_gro_receive(&mp->napi, skb);
continue;
@@ -624,9 +578,6 @@ err:
dev_kfree_skb(skb);
}
- if (lro_flush_needed)
- lro_flush_all(&rxq->lro_mgr);
-
if (rx < budget)
mp->work_rx &= ~(1 << rxq->index);
@@ -1118,26 +1069,6 @@ static struct net_device_stats *mv643xx_eth_get_stats(struct net_device *dev)
return stats;
}
-static void mv643xx_eth_grab_lro_stats(struct mv643xx_eth_private *mp)
-{
- u32 lro_aggregated = 0;
- u32 lro_flushed = 0;
- u32 lro_no_desc = 0;
- int i;
-
- for (i = 0; i < mp->rxq_count; i++) {
- struct rx_queue *rxq = mp->rxq + i;
-
- lro_aggregated += rxq->lro_mgr.stats.aggregated;
- lro_flushed += rxq->lro_mgr.stats.flushed;
- lro_no_desc += rxq->lro_mgr.stats.no_desc;
- }
-
- mp->lro_counters.lro_aggregated = lro_aggregated;
- mp->lro_counters.lro_flushed = lro_flushed;
- mp->lro_counters.lro_no_desc = lro_no_desc;
-}
-
static inline u32 mib_read(struct mv643xx_eth_private *mp, int offset)
{
return rdl(mp, MIB_COUNTERS(mp->port_num) + offset);
@@ -1301,10 +1232,6 @@ struct mv643xx_eth_stats {
{ #m, FIELD_SIZEOF(struct mib_counters, m), \
-1, offsetof(struct mv643xx_eth_private, mib_counters.m) }
-#define LROSTAT(m) \
- { #m, FIELD_SIZEOF(struct lro_counters, m), \
- -1, offsetof(struct mv643xx_eth_private, lro_counters.m) }
-
static const struct mv643xx_eth_stats mv643xx_eth_stats[] = {
SSTAT(rx_packets),
SSTAT(tx_packets),
@@ -1346,9 +1273,6 @@ static const struct mv643xx_eth_stats mv643xx_eth_stats[] = {
MIBSTAT(late_collision),
MIBSTAT(rx_discard),
MIBSTAT(rx_overrun),
- LROSTAT(lro_aggregated),
- LROSTAT(lro_flushed),
- LROSTAT(lro_no_desc),
};
static int
@@ -1578,7 +1502,6 @@ static void mv643xx_eth_get_ethtool_stats(struct net_device *dev,
mv643xx_eth_get_stats(dev);
mib_counters_update(mp);
- mv643xx_eth_grab_lro_stats(mp);
for (i = 0; i < ARRAY_SIZE(mv643xx_eth_stats); i++) {
const struct mv643xx_eth_stats *stat;
@@ -1851,19 +1774,6 @@ static int rxq_init(struct mv643xx_eth_private *mp, int index)
nexti * sizeof(struct rx_desc);
}
- rxq->lro_mgr.dev = mp->dev;
- memset(&rxq->lro_mgr.stats, 0, sizeof(rxq->lro_mgr.stats));
- rxq->lro_mgr.features = LRO_F_NAPI;
- rxq->lro_mgr.ip_summed = CHECKSUM_UNNECESSARY;
- rxq->lro_mgr.ip_summed_aggr = CHECKSUM_UNNECESSARY;
- rxq->lro_mgr.max_desc = ARRAY_SIZE(rxq->lro_arr);
- rxq->lro_mgr.max_aggr = 32;
- rxq->lro_mgr.frag_align_pad = 0;
- rxq->lro_mgr.lro_arr = rxq->lro_arr;
- rxq->lro_mgr.get_skb_header = mv643xx_get_skb_header;
-
- memset(&rxq->lro_arr, 0, sizeof(rxq->lro_arr));
-
return 0;
@@ -2851,8 +2761,7 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
dev->watchdog_timeo = 2 * HZ;
dev->base_addr = 0;
- dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM |
- NETIF_F_RXCSUM | NETIF_F_LRO;
+ dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_RXCSUM;
dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_RXCSUM;
dev->vlan_features = NETIF_F_SG | NETIF_F_IP_CSUM;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] bookehv: Handle debug exception on guest exit
From: Stuart Yoder @ 2013-04-11 18:44 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, KVM list, Alexander Graf, kvm-ppc,
Yoder Stuart-B08248, Bhushan Bharat-R65777, linuxppc list
In-Reply-To: <CALRxmdD7ZWj4PM5VTZz_RimmgQAJCX=5yUx=H+7-W30r-PdTtA@mail.gmail.com>
So the patch should look something like this (on a 3.8 kernel):
diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index 5f051ee..92b675a 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -286,13 +286,13 @@ label:
andis. r10,r10,(DBSR_IC|DBSR_BT)@h; \
beq+ 2f; \
\
- lis r10,KERNELBASE@h; /* check if exception in vectors */ \
- ori r10,r10,KERNELBASE@l; \
+ lis r10,interrupt_base@h; /* check if exception in vectors */ \
+ ori r10,r10,interrupt_base@l;
cmplw r12,r10; \
blt+ 2f; /* addr below exception vectors */ \
\
- lis r10,DebugDebug@h; \
- ori r10,r10,DebugDebug@l; \
+ lis r10,interrupt_end@h; \
+ ori r10,r10,interrupt_end@l;
cmplw r12,r10; \
bgt+ 2f; /* addr above exception vectors */ \
\
@@ -339,13 +339,13 @@ label:
andis. r10,r10,(DBSR_IC|DBSR_BT)@h; \
beq+ 2f; \
\
- lis r10,KERNELBASE@h; /* check if exception in vectors */ \
- ori r10,r10,KERNELBASE@l; \
+ lis r10,interrupt_base@h; /* check if exception in vectors */ \
+ ori r10,r10,interrupt_base@l;
cmplw r12,r10; \
blt+ 2f; /* addr below exception vectors */ \
\
- lis r10,DebugCrit@h; \
- ori r10,r10,DebugCrit@l; \
+ lis r10,interrupt_end@h; \
+ ori r10,r10,interrupt_end@l;
cmplw r12,r10; \
bgt+ 2f; /* addr above exception vectors */ \
\
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index 7a2e5e4..97e2671 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -769,6 +769,8 @@ finish_tlb_load_47x:
*/
DEBUG_CRIT_EXCEPTION
+interrupt_end:
+
/*
* Global functions
*/
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl
index 58925b6..2c3e31d 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -605,6 +605,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
/* Embedded Hypervisor Privilege */
EXCEPTION(0, HV_PRIV, Ehvpriv, unknown_exception, EXC_XFER_EE)
+interrupt_end:
+
/*
* Local functions
*/
^ permalink raw reply related
* Re: recommended method of netbooting kernel/dtb in u-boot?
From: Chris Friesen @ 2013-04-11 18:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <3B81A930-A4AB-4AA7-BC36-FCCE55D33C66@kernel.crashing.org>
On 04/11/2013 12:12 PM, Kumar Gala wrote:
>
> On Apr 11, 2013, at 10:44 AM, Chris Friesen wrote:
>
>>
>> Hi all,
>>
>> We've got a powerpc system that uses u-boot. In our environment on
>> bootup u-boot does a DHCP to get networking info, then uses TFTP to
>> get the kernel, which then does DHCP again and NFS-mounts the
>> initial root filesystem.
>>
>> What's the standard practice for this sort of thing when using
>> device tree blobs? Do most people use multi-file images or do they
>> TFTP scripts to load and execute separate kernel/dtb files?
>
> We've normally just done multiple tftp fetches and one grabs dtb and
> one grabs kernel.
Do you hardcode the path to the file in the firmware? Or do you upload
a script that knows the path to the file?
In our case the path to the boot file(s) depends on which slot the card
being booted has been inserted in. The DHCP server knows what the path
is, so it can set dhcpd.conf appropriately, but we need to get that
information to the firmware on the card being booted.
Chris
^ permalink raw reply
* Re: [PATCH] bookehv: Handle debug exception on guest exit
From: Stuart Yoder @ 2013-04-11 18:37 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, KVM list, Alexander Graf, kvm-ppc,
Yoder Stuart-B08248, Bhushan Bharat-R65777, linuxppc list
In-Reply-To: <5A04ECFC-E828-4EBF-895B-043FC038ABB5@kernel.crashing.org>
On Thu, Apr 11, 2013 at 1:33 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Apr 5, 2013, at 2:53 AM, Bhushan Bharat-R65777 wrote:
>
>> Hi Kumar/Benh,
>>
>> After further looking into the code I think that if we correct the vector range below in DebugDebug handler then we do not need the change I provided in this patch.
>>
>> Here is the snapshot for 32 bit (head_booke.h, same will be true for 64 bit):
>>
>> #define DEBUG_DEBUG_EXCEPTION \
>> START_EXCEPTION(DebugDebug); \
>> DEBUG_EXCEPTION_PROLOG; \
>> \
>> /* \
>> * If there is a single step or branch-taken exception in an \
>> * exception entry sequence, it was probably meant to apply to \
>> * the code where the exception occurred (since exception entry \
>> * doesn't turn off DE automatically). We simulate the effect \
>> * of turning off DE on entry to an exception handler by turning \
>> * off DE in the DSRR1 value and clearing the debug status. \
>> */ \
>> mfspr r10,SPRN_DBSR; /* check single-step/branch taken */ \
>> andis. r10,r10,(DBSR_IC|DBSR_BT)@h; \
>> beq+ 2f; \
>> \
>> lis r10,KERNELBASE@h; /* check if exception in vectors */ \
>> ori r10,r10,KERNELBASE@l; \
>> cmplw r12,r10; \
>> blt+ 2f; /* addr below exception vectors */ \
>> \
>> lis r10,DebugDebug@h; \
>> ori r10,r10,DebugDebug@l; \
>>
>> ^^^^
>> Here we assume all exception vector ends at DebugDebug, which is not correct.
>> We probably should get proper end by using some start_vector and end_vector lebels
>> or at least use end at Ehvpriv (which is last defined in head_fsl_booke.S for PowerPC. Is that correct?
>>
>>
>> cmplw r12,r10; \
>> bgt+ 2f; /* addr above exception vectors */ \
>>
>> Thanks
>> -Bharat
>
> I talked to Stuart and this general approach is good. Just make sure to update both head_44x.S and head_fsl_booke.S. Plus do this for both DEBUG_CRIT_EXCEPTION & DEBUG_DEBUG_EXCEPTION
Also, it looks like 64-bit already handles this properly with symbols
identifying the
start/end of the vectors (exceptions-64e.S).
Stuart
^ permalink raw reply
* Re: [PATCH] bookehv: Handle debug exception on guest exit
From: Kumar Gala @ 2013-04-11 18:33 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, KVM list, Alexander Graf, kvm-ppc,
Yoder Stuart-B08248, linuxppc list
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D06FC1773@039-SN2MPN1-013.039d.mgd.msft.net>
On Apr 5, 2013, at 2:53 AM, Bhushan Bharat-R65777 wrote:
> Hi Kumar/Benh,
>=20
> After further looking into the code I think that if we correct the =
vector range below in DebugDebug handler then we do not need the change =
I provided in this patch.
>=20
> Here is the snapshot for 32 bit (head_booke.h, same will be true for =
64 bit):
>=20
> #define DEBUG_DEBUG_EXCEPTION =
\
> START_EXCEPTION(DebugDebug); =
\
> DEBUG_EXCEPTION_PROLOG; =
\
> =
\
> /* =
\
> * If there is a single step or branch-taken exception in an =
\
> * exception entry sequence, it was probably meant to apply to =
\
> * the code where the exception occurred (since exception entry =
\
> * doesn't turn off DE automatically). We simulate the effect =
\
> * of turning off DE on entry to an exception handler by =
turning \
> * off DE in the DSRR1 value and clearing the debug status. =
\
> */ =
\
> mfspr r10,SPRN_DBSR; /* check single-step/branch =
taken */ \
> andis. r10,r10,(DBSR_IC|DBSR_BT)@h; =
\
> beq+ 2f; =
\
> =
\
> lis r10,KERNELBASE@h; /* check if exception in =
vectors */ \
> ori r10,r10,KERNELBASE@l; =
\
> cmplw r12,r10; =
\
> blt+ 2f; /* addr below exception vectors =
*/ \
> =
\
> lis r10,DebugDebug@h; =
\
> ori r10,r10,DebugDebug@l; =
\
>=20
> ^^^^
> Here we assume all exception vector ends at DebugDebug, which is =
not correct.
> We probably should get proper end by using some start_vector and =
end_vector lebels
> or at least use end at Ehvpriv (which is last defined in =
head_fsl_booke.S for PowerPC. Is that correct?
>=20
> =09
> cmplw r12,r10; =
\
> bgt+ 2f; /* addr above exception vectors =
*/ \
>=20
> Thanks
> -Bharat
I talked to Stuart and this general approach is good. Just make sure to =
update both head_44x.S and head_fsl_booke.S. Plus do this for both =
DEBUG_CRIT_EXCEPTION & DEBUG_DEBUG_EXCEPTION
- k=
^ permalink raw reply
* Re: [PATCH 2/5 v11] powerpc: Add iommu domain pointer to device archdata
From: Kumar Gala @ 2013-04-11 18:16 UTC (permalink / raw)
To: Varun Sethi
Cc: joro, stuart.yoder, linux-kernel, iommu, scottwood, linuxppc-dev
In-Reply-To: <1364500442-20927-3-git-send-email-Varun.Sethi@freescale.com>
On Mar 28, 2013, at 2:53 PM, Varun Sethi wrote:
> Add an iommu domain pointer to device (powerpc) archdata. Devices
> are attached to iommu domains and this pointer provides a mechanism
> to correlate between a device and the associated iommu domain. This
> field is set when a device is attached to a domain.
>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> ---
> - no change in v11.
> - no change in v10.
> - Added CONFIG_IOMMU_API in v9.
> arch/powerpc/include/asm/device.h | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
Acked-by: Kumar Gala <galak@kernel.crashing.org>
- k
^ permalink raw reply
* Re: recommended method of netbooting kernel/dtb in u-boot?
From: Kumar Gala @ 2013-04-11 18:12 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev
In-Reply-To: <5166DA49.5000907@genband.com>
On Apr 11, 2013, at 10:44 AM, Chris Friesen wrote:
>=20
> Hi all,
>=20
> We've got a powerpc system that uses u-boot. In our environment on =
bootup u-boot does a DHCP to get networking info, then uses TFTP to get =
the kernel, which then does DHCP again and NFS-mounts the initial root =
filesystem.
>=20
> What's the standard practice for this sort of thing when using device =
tree blobs? Do most people use multi-file images or do they TFTP =
scripts to load and execute separate kernel/dtb files?
>=20
> For multi-part images is there an in-kernel way of generating a file =
containing a kernel and dtb combined? I saw a patch proposed in 2008 to =
add a uImage.<dt> build target but it was shot down because it used the =
legacy multi-file format. Is there an equivalent build target that uses =
the FIT format?
We've normally just done multiple tftp fetches and one grabs dtb and one =
grabs kernel.
- k=
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Sebastian Hesselbarth @ 2013-04-11 18:07 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek
In-Reply-To: <1365702955.7355.5.camel@bwh-desktop.uk.solarflarecom.com>
On 04/11/2013 07:55 PM, Ben Hutchings wrote:
> On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote:
>> This patch adds GRO support to mv643xx_eth by making it invoke
>> napi_gro_receive instead of netif_receive_skb.
>
> The inet_lro support should be removed at the same time; inet_lro is now
> deprecated and there should be no need to keep both of them.
Ben,
I agree on removing it asap, but I also like to see GRO support
in. Maybe, we postpone lro removal just a little bit. I have just
started to look at mv643xx_eth and remember Marvell Orion SoCs are
not the only platform using it. I haven't heard a single word from
ppc guys, yet.
Willy just posted an experimental patch to remove lro. I'll have
a look at it and test it out on Dove.
Sebastian
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Willy Tarreau @ 2013-04-11 18:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: andrew, jason, linux-kernel, florian, smoch, paulus,
linux-arm-kernel, dale, netdev, linuxppc-dev, David Miller,
buytenh, sebastian.hesselbarth
In-Reply-To: <1365703155.3887.184.camel@edumazet-glaptop>
On Thu, Apr 11, 2013 at 10:59:15AM -0700, Eric Dumazet wrote:
> On Thu, 2013-04-11 at 19:51 +0200, Willy Tarreau wrote:
>
> > Eric provided me with one such experimental patch in the past for this
> > driver. It worked for me but we never tried to clean it up to propose
> > it for inclusion.
> >
> > If anyone is interested, I might still have it in experimental shape.
>
> We are interested a lot ;)
Just found it in one of my local branches :-)
Here it is. It was experimental. At first glance, I'm seeing it does not
remove NETIF_F_LRO as we used it for experimentation only, but that's
a trivial thing to fix.
Original work by you Eric, tested by me on 3.6.
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index ea2cedc..81a6cb0 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -55,9 +55,9 @@
#include <linux/mv643xx_eth.h>
#include <linux/io.h>
#include <linux/types.h>
-#include <linux/inet_lro.h>
#include <linux/slab.h>
#include <linux/clk.h>
+#include <linux/interrupt.h>
static char mv643xx_eth_driver_name[] = "mv643xx_eth";
static char mv643xx_eth_driver_version[] = "1.4";
@@ -343,12 +343,6 @@ struct mib_counters {
u32 rx_overrun;
};
-struct lro_counters {
- u32 lro_aggregated;
- u32 lro_flushed;
- u32 lro_no_desc;
-};
-
struct rx_queue {
int index;
@@ -363,8 +357,6 @@ struct rx_queue {
int rx_desc_area_size;
void **rx_data;
unsigned int frag_size;
- struct net_lro_mgr lro_mgr;
- struct net_lro_desc lro_arr[8];
};
struct tx_queue {
@@ -400,8 +392,6 @@ struct mv643xx_eth_private {
spinlock_t mib_counters_lock;
struct mib_counters mib_counters;
- struct lro_counters lro_counters;
-
struct work_struct tx_timeout_task;
struct napi_struct napi;
@@ -533,33 +523,6 @@ static void txq_maybe_wake(struct tx_queue *txq)
}
-/* rx napi ******************************************************************/
-static int
-mv643xx_get_skb_header(struct sk_buff *skb, void **iphdr, void **tcph,
- u64 *hdr_flags, void *priv)
-{
- unsigned long cmd_sts = (unsigned long)priv;
-
- /*
- * Make sure that this packet is Ethernet II, is not VLAN
- * tagged, is IPv4, has a valid IP header, and is TCP.
- */
- if ((cmd_sts & (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
- RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_MASK |
- RX_PKT_IS_VLAN_TAGGED)) !=
- (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
- RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_TCP_IPV4))
- return -1;
-
- skb_reset_network_header(skb);
- skb_set_transport_header(skb, ip_hdrlen(skb));
- *iphdr = ip_hdr(skb);
- *tcph = tcp_hdr(skb);
- *hdr_flags = LRO_IPV4 | LRO_TCP;
-
- return 0;
-}
-
static void mv_frag_free(const struct rx_queue *rxq, void *data)
{
if (rxq->frag_size)
@@ -568,14 +531,12 @@ static void mv_frag_free(const struct rx_queue *rxq, void *data)
kfree(data);
}
-static int rxq_process(struct rx_queue *rxq, int budget)
+static int rxq_process(struct napi_struct *napi, struct rx_queue *rxq, int budget)
{
struct mv643xx_eth_private *mp = rxq_to_mp(rxq);
struct net_device_stats *stats = &mp->dev->stats;
- int lro_flush_needed;
int rx;
- lro_flush_needed = 0;
rx = 0;
while (rx < budget && rxq->rx_desc_count) {
struct rx_desc *rx_desc;
@@ -646,12 +607,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->protocol = eth_type_trans(skb, mp->dev);
- if (skb->dev->features & NETIF_F_LRO &&
- skb->ip_summed == CHECKSUM_UNNECESSARY) {
- lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
- lro_flush_needed = 1;
- } else
- netif_receive_skb(skb);
+ napi_gro_receive(napi, skb);
continue;
@@ -671,9 +627,6 @@ err:
dev_kfree_skb(skb);
}
- if (lro_flush_needed)
- lro_flush_all(&rxq->lro_mgr);
-
if (rx < budget)
mp->work_rx &= ~(1 << rxq->index);
@@ -723,7 +676,6 @@ static int rxq_refill(struct rx_queue *rxq, int budget)
rxq->rx_data[rx] = data;
wmb();
rx_desc->cmd_sts = BUFFER_OWNED_BY_DMA | RX_ENABLE_INTERRUPT;
-
}
if (refilled < budget)
@@ -1214,26 +1166,6 @@ static struct net_device_stats *mv643xx_eth_get_stats(struct net_device *dev)
return stats;
}
-static void mv643xx_eth_grab_lro_stats(struct mv643xx_eth_private *mp)
-{
- u32 lro_aggregated = 0;
- u32 lro_flushed = 0;
- u32 lro_no_desc = 0;
- int i;
-
- for (i = 0; i < mp->rxq_count; i++) {
- struct rx_queue *rxq = mp->rxq + i;
-
- lro_aggregated += rxq->lro_mgr.stats.aggregated;
- lro_flushed += rxq->lro_mgr.stats.flushed;
- lro_no_desc += rxq->lro_mgr.stats.no_desc;
- }
-
- mp->lro_counters.lro_aggregated = lro_aggregated;
- mp->lro_counters.lro_flushed = lro_flushed;
- mp->lro_counters.lro_no_desc = lro_no_desc;
-}
-
static inline u32 mib_read(struct mv643xx_eth_private *mp, int offset)
{
return rdl(mp, MIB_COUNTERS(mp->port_num) + offset);
@@ -1397,10 +1329,6 @@ struct mv643xx_eth_stats {
{ #m, FIELD_SIZEOF(struct mib_counters, m), \
-1, offsetof(struct mv643xx_eth_private, mib_counters.m) }
-#define LROSTAT(m) \
- { #m, FIELD_SIZEOF(struct lro_counters, m), \
- -1, offsetof(struct mv643xx_eth_private, lro_counters.m) }
-
static const struct mv643xx_eth_stats mv643xx_eth_stats[] = {
SSTAT(rx_packets),
SSTAT(tx_packets),
@@ -1442,9 +1370,6 @@ static const struct mv643xx_eth_stats mv643xx_eth_stats[] = {
MIBSTAT(late_collision),
MIBSTAT(rx_discard),
MIBSTAT(rx_overrun),
- LROSTAT(lro_aggregated),
- LROSTAT(lro_flushed),
- LROSTAT(lro_no_desc),
};
static int
@@ -1642,7 +1567,6 @@ static void mv643xx_eth_get_ethtool_stats(struct net_device *dev,
mv643xx_eth_get_stats(dev);
mib_counters_update(mp);
- mv643xx_eth_grab_lro_stats(mp);
for (i = 0; i < ARRAY_SIZE(mv643xx_eth_stats); i++) {
const struct mv643xx_eth_stats *stat;
@@ -1915,19 +1839,6 @@ static int rxq_init(struct mv643xx_eth_private *mp, int index)
nexti * sizeof(struct rx_desc);
}
- rxq->lro_mgr.dev = mp->dev;
- memset(&rxq->lro_mgr.stats, 0, sizeof(rxq->lro_mgr.stats));
- rxq->lro_mgr.features = LRO_F_NAPI;
- rxq->lro_mgr.ip_summed = CHECKSUM_UNNECESSARY;
- rxq->lro_mgr.ip_summed_aggr = CHECKSUM_UNNECESSARY;
- rxq->lro_mgr.max_desc = ARRAY_SIZE(rxq->lro_arr);
- rxq->lro_mgr.max_aggr = 32;
- rxq->lro_mgr.frag_align_pad = 0;
- rxq->lro_mgr.lro_arr = rxq->lro_arr;
- rxq->lro_mgr.get_skb_header = mv643xx_get_skb_header;
-
- memset(&rxq->lro_arr, 0, sizeof(rxq->lro_arr));
-
return 0;
@@ -2192,7 +2103,7 @@ static int mv643xx_eth_poll(struct napi_struct *napi, int budget)
work_done += txq_reclaim(mp->txq + queue, work_tbd, 0);
txq_maybe_wake(mp->txq + queue);
} else if (mp->work_rx & queue_mask) {
- work_done += rxq_process(mp->rxq + queue, work_tbd);
+ work_done += rxq_process(napi, mp->rxq + queue, work_tbd);
} else if (!mp->oom && (mp->work_rx_refill & queue_mask)) {
work_done += rxq_refill(mp->rxq + queue, work_tbd);
} else {
Regards,
Willy
^ permalink raw reply related
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Ben Hutchings @ 2013-04-11 17:55 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek
In-Reply-To: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote:
> This patch adds GRO support to mv643xx_eth by making it invoke
> napi_gro_receive instead of netif_receive_skb.
The inet_lro support should be removed at the same time; inet_lro is now
deprecated and there should be no need to keep both of them.
Ben.
> Signed-off-by: Soeren Moch <smoch@web.de>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Lennert Buytenhek <buytenh@wantstofly.org>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Florian Fainelli <florian@openwrt.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Dale Farnsworth <dale@farnsworth.org>
> Cc: netdev@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index 305038f..c850d04 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
> lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
> lro_flush_needed = 1;
> } else
> - netif_receive_skb(skb);
> + napi_gro_receive(&mp->napi, skb);
>
> continue;
>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Eric Dumazet @ 2013-04-11 17:59 UTC (permalink / raw)
To: Willy Tarreau
Cc: andrew, jason, linux-kernel, florian, smoch, paulus,
linux-arm-kernel, dale, netdev, linuxppc-dev, David Miller,
buytenh, sebastian.hesselbarth
In-Reply-To: <20130411175147.GN1910@1wt.eu>
On Thu, 2013-04-11 at 19:51 +0200, Willy Tarreau wrote:
> Eric provided me with one such experimental patch in the past for this
> driver. It worked for me but we never tried to clean it up to propose
> it for inclusion.
>
> If anyone is interested, I might still have it in experimental shape.
We are interested a lot ;)
Thanks !
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Willy Tarreau @ 2013-04-11 17:51 UTC (permalink / raw)
To: David Miller
Cc: andrew, jason, linux-kernel, smoch, paulus, linux-arm-kernel,
dale, netdev, linuxppc-dev, florian, buytenh,
sebastian.hesselbarth
In-Reply-To: <20130411.133119.913809939413807690.davem@davemloft.net>
On Thu, Apr 11, 2013 at 01:31:19PM -0400, David Miller wrote:
> From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Date: Thu, 11 Apr 2013 17:27:03 +0200
>
> > On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau <w@1wt.eu> wrote:
> >> On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
> >>> I tried todays net-next on top of 3.9-rc6 without any gro patch, with
> >>> the initial
> >>> patch (Soeren) and your proposed patch (Willy). The results show that
> >>> both patches
> >>> allow a significant increase in throughput compared to
> >>> netif_receive_skb (!gro, !lro)
> >>> alone. Having gro with lro disabled gives some 2% more throughput
> >>> compared to lro only.
> >>
> >> Indeed this is consistent with my memories, since Eric improved the
> >> GRO path, it became faster than LRO on this chip.
> >
> > I don't have a strong opinion on whether Soeren's or your proposal should
> > be submitted. But I insist on having one of them in, as GRO significantly
> > improves the common use case, is enabled by default, and not as
> > constrained as LRO.
>
> I think, as per other drivers, LRO should be eliminated completely from
> all drivers, including this one, and GRO used exclusively instead.
Eric provided me with one such experimental patch in the past for this
driver. It worked for me but we never tried to clean it up to propose
it for inclusion.
If anyone is interested, I might still have it in experimental shape.
Willy
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Eric Dumazet @ 2013-04-11 17:35 UTC (permalink / raw)
To: David Miller
Cc: andrew, jason, linux-kernel, florian, smoch, paulus,
linux-arm-kernel, dale, netdev, linuxppc-dev, w, buytenh,
sebastian.hesselbarth
In-Reply-To: <20130411.133119.913809939413807690.davem@davemloft.net>
On Thu, 2013-04-11 at 13:31 -0400, David Miller wrote:
> I think, as per other drivers, LRO should be eliminated completely from
> all drivers, including this one, and GRO used exclusively instead.
This would be awesome.
AFAIK current LRO users are :
drivers/infiniband/hw/nes/nes_hw.c
drivers/net/ethernet/marvell/mv643xx_eth.c
drivers/net/ethernet/pasemi/pasemi_mac.c
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: David Miller @ 2013-04-11 17:31 UTC (permalink / raw)
To: sebastian.hesselbarth
Cc: andrew, jason, linux-kernel, w, smoch, paulus, linux-arm-kernel,
dale, netdev, linuxppc-dev, florian, buytenh
In-Reply-To: <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Date: Thu, 11 Apr 2013 17:27:03 +0200
> On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau <w@1wt.eu> wrote:
>> On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
>>> I tried todays net-next on top of 3.9-rc6 without any gro patch, with
>>> the initial
>>> patch (Soeren) and your proposed patch (Willy). The results show that
>>> both patches
>>> allow a significant increase in throughput compared to
>>> netif_receive_skb (!gro, !lro)
>>> alone. Having gro with lro disabled gives some 2% more throughput
>>> compared to lro only.
>>
>> Indeed this is consistent with my memories, since Eric improved the
>> GRO path, it became faster than LRO on this chip.
>
> I don't have a strong opinion on whether Soeren's or your proposal should
> be submitted. But I insist on having one of them in, as GRO significantly
> improves the common use case, is enabled by default, and not as
> constrained as LRO.
I think, as per other drivers, LRO should be eliminated completely from
all drivers, including this one, and GRO used exclusively instead.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Willy Tarreau @ 2013-04-11 17:13 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek
In-Reply-To: <CABJ1b_QaEJbuBsqx+J1Pkc7o66S_Rboa7Trnko1mXSK6-UZhfg@mail.gmail.com>
On Thu, Apr 11, 2013 at 06:59:11PM +0200, Sebastian Hesselbarth wrote:
> On Thu, Apr 11, 2013 at 5:32 PM, Willy Tarreau <w@1wt.eu> wrote:
> > On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> >> I don't have a strong opinion on whether Soeren's or your proposal should
> >> be submitted. But I insist on having one of them in, as GRO significantly
> >> improves the common use case, is enabled by default, and not as
> >> constrained as LRO.
> >
> > I agree, use yours first, but we should keep an eye on this. Since you have
> > everything to run a test, please try to see if you can get netperf to run
> > over IPv6, I'm sure the NIC doesn't handle it.
>
> Willy,
>
> out of curiosity I replayed all tests using netperf/netserver with -6 which
> enables ipv6. The overall results remain quite the same here:
> enabling support for GRO gives a huge improvement in achievable
> throughput, and the difference between Soeren's and your patch is
> neglectible.
Perfect, thank you for testing this !
Best regards,
Willy
^ 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