* [PATCH v2 3/7] via-velocity: Implement NAPI support
From: Simon Kagstrom @ 2009-11-23 14:31 UTC (permalink / raw)
To: netdev; +Cc: davem, davej, shemminger, romieu
In-Reply-To: <20091123152724.2871cf4d@marrow.netinsight.se>
This patch adds NAPI support for VIA velocity. The new velocity_poll
function also pairs tx/rx handling twice which improves perforamance on
some workloads (e.g., netperf UDP_STREAM) significantly (that part is
from the VIA driver).
Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
---
drivers/net/via-velocity.c | 81 +++++++++++++++++++++++++-------------------
drivers/net/via-velocity.h | 3 ++
2 files changed, 49 insertions(+), 35 deletions(-)
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index 85ee898..668cdf6 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -354,12 +354,6 @@ VELOCITY_PARAM(ValPktLen, "Receiving or Drop invalid 802.3 frame");
*/
VELOCITY_PARAM(wol_opts, "Wake On Lan options");
-#define INT_WORKS_DEF 20
-#define INT_WORKS_MIN 10
-#define INT_WORKS_MAX 64
-
-VELOCITY_PARAM(int_works, "Number of packets per interrupt services");
-
static int rx_copybreak = 200;
module_param(rx_copybreak, int, 0644);
MODULE_PARM_DESC(rx_copybreak, "Copy breakpoint for copy-only-tiny-frames");
@@ -516,7 +510,6 @@ static void __devinit velocity_get_options(struct velocity_opt *opts, int index,
velocity_set_bool_opt(&opts->flags, ValPktLen[index], VAL_PKT_LEN_DEF, VELOCITY_FLAGS_VAL_PKT_LEN, "ValPktLen", devname);
velocity_set_int_opt((int *) &opts->spd_dpx, speed_duplex[index], MED_LNK_MIN, MED_LNK_MAX, MED_LNK_DEF, "Media link mode", devname);
velocity_set_int_opt((int *) &opts->wol_opts, wol_opts[index], WOL_OPT_MIN, WOL_OPT_MAX, WOL_OPT_DEF, "Wake On Lan options", devname);
- velocity_set_int_opt((int *) &opts->int_works, int_works[index], INT_WORKS_MIN, INT_WORKS_MAX, INT_WORKS_DEF, "Interrupt service works", devname);
opts->numrx = (opts->numrx & ~3);
}
@@ -2123,13 +2116,14 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
* any received packets from the receive queue. Hand the ring
* slots back to the adapter for reuse.
*/
-static int velocity_rx_srv(struct velocity_info *vptr, int status)
+static int velocity_rx_srv(struct velocity_info *vptr, int status,
+ int budget_left)
{
struct net_device_stats *stats = &vptr->dev->stats;
int rd_curr = vptr->rx.curr;
int works = 0;
- do {
+ while (works < budget_left) {
struct rx_desc *rd = vptr->rx.ring + rd_curr;
if (!vptr->rx.info[rd_curr].skb)
@@ -2160,7 +2154,8 @@ static int velocity_rx_srv(struct velocity_info *vptr, int status)
rd_curr++;
if (rd_curr >= vptr->options.numrx)
rd_curr = 0;
- } while (++works <= 15);
+ works++;
+ }
vptr->rx.curr = rd_curr;
@@ -2171,6 +2166,40 @@ static int velocity_rx_srv(struct velocity_info *vptr, int status)
return works;
}
+static int velocity_poll(struct napi_struct *napi, int budget)
+{
+ struct velocity_info *vptr = container_of(napi,
+ struct velocity_info, napi);
+ unsigned int rx_done;
+ u32 isr_status;
+
+ spin_lock(&vptr->lock);
+ isr_status = mac_read_isr(vptr->mac_regs);
+
+ /* Ack the interrupt */
+ mac_write_isr(vptr->mac_regs, isr_status);
+ if (isr_status & (~(ISR_PRXI | ISR_PPRXI | ISR_PTXI | ISR_PPTXI)))
+ velocity_error(vptr, isr_status);
+
+ /*
+ * Do rx and tx twice for performance (taken from the VIA
+ * out-of-tree driver).
+ */
+ rx_done = velocity_rx_srv(vptr, isr_status, budget / 2);
+ velocity_tx_srv(vptr, isr_status);
+ rx_done += velocity_rx_srv(vptr, isr_status, budget - rx_done);
+ velocity_tx_srv(vptr, isr_status);
+
+ spin_unlock(&vptr->lock);
+
+ /* If budget not fully consumed, exit the polling mode */
+ if (rx_done < budget) {
+ napi_complete(napi);
+ mac_enable_int(vptr->mac_regs);
+ }
+
+ return rx_done;
+}
/**
* velocity_intr - interrupt callback
@@ -2187,8 +2216,6 @@ static irqreturn_t velocity_intr(int irq, void *dev_instance)
struct net_device *dev = dev_instance;
struct velocity_info *vptr = netdev_priv(dev);
u32 isr_status;
- int max_count = 0;
-
spin_lock(&vptr->lock);
isr_status = mac_read_isr(vptr->mac_regs);
@@ -2199,32 +2226,13 @@ static irqreturn_t velocity_intr(int irq, void *dev_instance)
return IRQ_NONE;
}
- mac_disable_int(vptr->mac_regs);
-
- /*
- * Keep processing the ISR until we have completed
- * processing and the isr_status becomes zero
- */
-
- while (isr_status != 0) {
- mac_write_isr(vptr->mac_regs, isr_status);
- if (isr_status & (~(ISR_PRXI | ISR_PPRXI | ISR_PTXI | ISR_PPTXI)))
- velocity_error(vptr, isr_status);
- if (isr_status & (ISR_PRXI | ISR_PPRXI))
- max_count += velocity_rx_srv(vptr, isr_status);
- if (isr_status & (ISR_PTXI | ISR_PPTXI))
- max_count += velocity_tx_srv(vptr, isr_status);
- isr_status = mac_read_isr(vptr->mac_regs);
- if (max_count > vptr->options.int_works) {
- printk(KERN_WARNING "%s: excessive work at interrupt.\n",
- dev->name);
- max_count = 0;
- }
+ if (likely(napi_schedule_prep(&vptr->napi))) {
+ mac_disable_int(vptr->mac_regs);
+ __napi_schedule(&vptr->napi);
}
spin_unlock(&vptr->lock);
- mac_enable_int(vptr->mac_regs);
- return IRQ_HANDLED;
+ return IRQ_HANDLED;
}
/**
@@ -2264,6 +2272,7 @@ static int velocity_open(struct net_device *dev)
mac_enable_int(vptr->mac_regs);
netif_start_queue(dev);
+ napi_enable(&vptr->napi);
vptr->flags |= VELOCITY_FLAGS_OPENED;
out:
return ret;
@@ -2499,6 +2508,7 @@ static int velocity_close(struct net_device *dev)
{
struct velocity_info *vptr = netdev_priv(dev);
+ napi_disable(&vptr->napi);
netif_stop_queue(dev);
velocity_shutdown(vptr);
@@ -2818,6 +2828,7 @@ static int __devinit velocity_found1(struct pci_dev *pdev, const struct pci_devi
dev->irq = pdev->irq;
dev->netdev_ops = &velocity_netdev_ops;
dev->ethtool_ops = &velocity_ethtool_ops;
+ netif_napi_add(dev, &vptr->napi, velocity_poll, VELOCITY_NAPI_WEIGHT);
dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_FILTER |
NETIF_F_HW_VLAN_RX;
diff --git a/drivers/net/via-velocity.h b/drivers/net/via-velocity.h
index 6091946..22bfea4 100644
--- a/drivers/net/via-velocity.h
+++ b/drivers/net/via-velocity.h
@@ -32,6 +32,7 @@
#define VELOCITY_VERSION "1.14"
#define VELOCITY_IO_SIZE 256
+#define VELOCITY_NAPI_WEIGHT 64
#define PKT_BUF_SZ 1540
@@ -1564,6 +1565,8 @@ struct velocity_info {
u32 ticks;
u8 rev_id;
+
+ struct napi_struct napi;
};
/**
--
1.6.0.4
^ permalink raw reply related
* [PATCH v2 2/7] via-velocity: Add ethtool interrupt coalescing support
From: Simon Kagstrom @ 2009-11-23 14:31 UTC (permalink / raw)
To: netdev; +Cc: davem, davej, shemminger, romieu
In-Reply-To: <20091123152724.2871cf4d@marrow.netinsight.se>
(Partially from the upstream VIA driver). Tweaking the number of
frames-per-interrupt and timer-until-interrupt can reduce the amount of
CPU work quite a lot.
Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
---
drivers/net/via-velocity.c | 160 +++++++++++++++++++++++++++++++++++++++++++-
drivers/net/via-velocity.h | 7 ++-
2 files changed, 165 insertions(+), 2 deletions(-)
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index b6cf3b5..85ee898 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -1259,6 +1259,66 @@ static void mii_init(struct velocity_info *vptr, u32 mii_status)
}
}
+/**
+ * setup_queue_timers - Setup interrupt timers
+ *
+ * Setup interrupt frequency during suppression (timeout if the frame
+ * count isn't filled).
+ */
+static void setup_queue_timers(struct velocity_info *vptr)
+{
+ /* Only for newer revisions */
+ if (vptr->rev_id >= REV_ID_VT3216_A0) {
+ u8 txqueue_timer = 0;
+ u8 rxqueue_timer = 0;
+
+ if (vptr->mii_status & (VELOCITY_SPEED_1000 |
+ VELOCITY_SPEED_100)) {
+ txqueue_timer = vptr->options.txqueue_timer;
+ rxqueue_timer = vptr->options.rxqueue_timer;
+ }
+
+ writeb(txqueue_timer, &vptr->mac_regs->TQETMR);
+ writeb(rxqueue_timer, &vptr->mac_regs->RQETMR);
+ }
+}
+/**
+ * setup_adaptive_interrupts - Setup interrupt suppression
+ *
+ * @vptr velocity adapter
+ *
+ * The velocity is able to suppress interrupt during high interrupt load.
+ * This function turns on that feature.
+ */
+static void setup_adaptive_interrupts(struct velocity_info *vptr)
+{
+ struct mac_regs __iomem *regs = vptr->mac_regs;
+ u16 tx_intsup = vptr->options.tx_intsup;
+ u16 rx_intsup = vptr->options.rx_intsup;
+
+ /* Setup default interrupt mask (will be changed below) */
+ vptr->int_mask = INT_MASK_DEF;
+
+ /* Set Tx Interrupt Suppression Threshold */
+ writeb(CAMCR_PS0, ®s->CAMCR);
+ if (tx_intsup != 0) {
+ vptr->int_mask &= ~(ISR_PTXI | ISR_PTX0I | ISR_PTX1I |
+ ISR_PTX2I | ISR_PTX3I);
+ writew(tx_intsup, ®s->ISRCTL);
+ } else
+ writew(ISRCTL_TSUPDIS, ®s->ISRCTL);
+
+ /* Set Rx Interrupt Suppression Threshold */
+ writeb(CAMCR_PS1, ®s->CAMCR);
+ if (rx_intsup != 0) {
+ vptr->int_mask &= ~ISR_PRXI;
+ writew(rx_intsup, ®s->ISRCTL);
+ } else
+ writew(ISRCTL_RSUPDIS, ®s->ISRCTL);
+
+ /* Select page to interrupt hold timer */
+ writeb(0, ®s->CAMCR);
+}
/**
* velocity_init_registers - initialise MAC registers
@@ -1345,7 +1405,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
*/
enable_mii_autopoll(regs);
- vptr->int_mask = INT_MASK_DEF;
+ setup_adaptive_interrupts(vptr);
writel(vptr->rx.pool_dma, ®s->RDBaseLo);
writew(vptr->options.numrx - 1, ®s->RDCSize);
@@ -1802,6 +1862,8 @@ static void velocity_error(struct velocity_info *vptr, int status)
BYTE_REG_BITS_OFF(TESTCFG_HBDIS, ®s->TESTCFG);
else
BYTE_REG_BITS_ON(TESTCFG_HBDIS, ®s->TESTCFG);
+
+ setup_queue_timers(vptr);
}
/*
* Get link status from PHYSR0
@@ -3223,6 +3285,100 @@ static void velocity_set_msglevel(struct net_device *dev, u32 value)
msglevel = value;
}
+static int get_pending_timer_val(int val)
+{
+ int mult_bits = val >> 6;
+ int mult = 1;
+
+ switch (mult_bits)
+ {
+ case 1:
+ mult = 4; break;
+ case 2:
+ mult = 16; break;
+ case 3:
+ mult = 64; break;
+ case 0:
+ default:
+ break;
+ }
+
+ return (val & 0x3f) * mult;
+}
+
+static void set_pending_timer_val(int *val, u32 us)
+{
+ u8 mult = 0;
+ u8 shift = 0;
+
+ if (us >= 0x3f) {
+ mult = 1; /* mult with 4 */
+ shift = 2;
+ }
+ if (us >= 0x3f * 4) {
+ mult = 2; /* mult with 16 */
+ shift = 4;
+ }
+ if (us >= 0x3f * 16) {
+ mult = 3; /* mult with 64 */
+ shift = 6;
+ }
+
+ *val = (mult << 6) | ((us >> shift) & 0x3f);
+}
+
+
+static int velocity_get_coalesce(struct net_device *dev,
+ struct ethtool_coalesce *ecmd)
+{
+ struct velocity_info *vptr = netdev_priv(dev);
+
+ ecmd->tx_max_coalesced_frames = vptr->options.tx_intsup;
+ ecmd->rx_max_coalesced_frames = vptr->options.rx_intsup;
+
+ ecmd->rx_coalesce_usecs = get_pending_timer_val(vptr->options.rxqueue_timer);
+ ecmd->tx_coalesce_usecs = get_pending_timer_val(vptr->options.txqueue_timer);
+
+ return 0;
+}
+
+static int velocity_set_coalesce(struct net_device *dev,
+ struct ethtool_coalesce *ecmd)
+{
+ struct velocity_info *vptr = netdev_priv(dev);
+ int max_us = 0x3f * 64;
+
+ /* 6 bits of */
+ if (ecmd->tx_coalesce_usecs > max_us)
+ return -EINVAL;
+ if (ecmd->rx_coalesce_usecs > max_us)
+ return -EINVAL;
+
+ if (ecmd->tx_max_coalesced_frames > 0xff)
+ return -EINVAL;
+ if (ecmd->rx_max_coalesced_frames > 0xff)
+ return -EINVAL;
+
+ vptr->options.rx_intsup = ecmd->rx_max_coalesced_frames;
+ vptr->options.tx_intsup = ecmd->tx_max_coalesced_frames;
+
+ set_pending_timer_val(&vptr->options.rxqueue_timer,
+ ecmd->rx_coalesce_usecs);
+ set_pending_timer_val(&vptr->options.txqueue_timer,
+ ecmd->tx_coalesce_usecs);
+
+ /* Setup the interrupt suppression and queue timers */
+ mac_disable_int(vptr->mac_regs);
+ setup_adaptive_interrupts(vptr);
+ setup_queue_timers(vptr);
+
+ mac_write_int_mask(vptr->int_mask, vptr->mac_regs);
+ mac_clear_isr(vptr->mac_regs);
+ mac_enable_int(vptr->mac_regs);
+
+ return 0;
+}
+
static const struct ethtool_ops velocity_ethtool_ops = {
.get_settings = velocity_get_settings,
.set_settings = velocity_set_settings,
@@ -3232,6 +3388,8 @@ static const struct ethtool_ops velocity_ethtool_ops = {
.get_msglevel = velocity_get_msglevel,
.set_msglevel = velocity_set_msglevel,
.get_link = velocity_get_link,
+ .get_coalesce = velocity_get_coalesce,
+ .set_coalesce = velocity_set_coalesce,
.begin = velocity_ethtool_up,
.complete = velocity_ethtool_down
};
diff --git a/drivers/net/via-velocity.h b/drivers/net/via-velocity.h
index 2f00c13..6091946 100644
--- a/drivers/net/via-velocity.h
+++ b/drivers/net/via-velocity.h
@@ -1005,7 +1005,8 @@ struct mac_regs {
volatile __le32 RDBaseLo; /* 0x38 */
volatile __le16 RDIdx; /* 0x3C */
- volatile __le16 reserved_3E;
+ volatile u8 TQETMR; /* 0x3E, VT3216 and above only */
+ volatile u8 RQETMR; /* 0x3F, VT3216 and above only */
volatile __le32 TDBaseLo[4]; /* 0x40 */
@@ -1491,6 +1492,10 @@ struct velocity_opt {
int rx_bandwidth_hi;
int rx_bandwidth_lo;
int rx_bandwidth_en;
+ int rxqueue_timer;
+ int txqueue_timer;
+ int tx_intsup;
+ int rx_intsup;
u32 flags;
};
--
1.6.0.4
^ permalink raw reply related
* [PATCH v2 1/7] via-velocity: Correct 64-byte alignment for rx buffers
From: Simon Kagstrom @ 2009-11-23 14:30 UTC (permalink / raw)
To: netdev; +Cc: davem, davej, shemminger, romieu
In-Reply-To: <20091123152724.2871cf4d@marrow.netinsight.se>
(From the VIA driver). The current code does not guarantee 64-byte
alignment since it simply does
int add = skb->data & 63;
skb->data += add;
(via skb_reserve). So for example, if the skb->data address would be
0x10, this would result in 32-byte alignment (0x10 + 0x10).
Correct by adding
64 - (skb->data & 63)
instead.
Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
---
drivers/net/via-velocity.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index e04e5be..b6cf3b5 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -1483,7 +1483,8 @@ static int velocity_alloc_rx_buf(struct velocity_info *vptr, int idx)
* Do the gymnastics to get the buffer head for data at
* 64byte alignment.
*/
- skb_reserve(rd_info->skb, (unsigned long) rd_info->skb->data & 63);
+ skb_reserve(rd_info->skb,
+ 64 - ((unsigned long) rd_info->skb->data & 63));
rd_info->skb_dma = pci_map_single(vptr->pdev, rd_info->skb->data,
vptr->rx.buf_sz, PCI_DMA_FROMDEVICE);
--
1.6.0.4
^ permalink raw reply related
* [PATCH v2 0/7] via-velocity performance fixes
From: Simon Kagstrom @ 2009-11-23 14:27 UTC (permalink / raw)
To: netdev; +Cc: davem, davej, shemminger, romieu
In-Reply-To: <20091120160633.77b7aee0@marrow.netinsight.se>
Hi again!
This is version two of the series posted here:
http://marc.info/?l=linux-netdev&m=125873023117769&w=2
The new version tries to integrate Stephen and Davids comments, and
also some general improvements which I've done. There are 7 patches:
1. See to it that data is 64-byte aligned (same as before)
2. Add ethtool interrupt coalescing support. This is the old "adaptive
interrupt suppression" patch, which is now implemented through the
ethtool interface. Both tx/rx frames and tx/rx time can be
controlled. The module parameters have been removed.
The default is everything off (i.e., as before).
3. NAPI support for via-velocity (same as before, but rebased)
4. Change DMA length default (same as before, rebased)
5. Re-enable scatter-gather support. This is also implemented through
ethtool, and therefore needs to be turned on. It's not always a win,
but for some netperf runs it improves stuff.
6. Set tx checksum from ethtool instead of a module parameter (new
patch)
7. Bump the version.
To get the same performance results as before, you now need to setup
interrupt supression with
ethtool -C eth-swa rx-usecs 20 tx-usecs 100 tx-frames 31 rx-frames 31
(which are the defaults from the VIA driver)
// Simon
^ permalink raw reply
* Re: ixgbe question
From: Jesper Dangaard Brouer @ 2009-11-23 14:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Peter P Waskiewicz Jr, Linux Netdev List
In-Reply-To: <4B0A6218.9040303@gmail.com>
On Mon, 23 Nov 2009, Eric Dumazet wrote:
> I tried a pktgen stress on 82599EB card and could not split RX load on multiple cpus.
>
> Setup is :
>
> One 82599 card with fiber0 looped to fiber1, 10Gb link mode.
> machine is a HPDL380 G6 with dual quadcore E5530 @2.4GHz (16 logical cpus)
>
> I use one pktgen thread sending to fiber0 one many dst IP, and checked that fiber1
> was using many RX queues :
How is your smp_affinity mask's set?
grep . /proc/irq/*/fiber1-*/../smp_affinity
> But only one CPU (CPU1) had a softirq running, 100%, and many frames were dropped
Just a hint, I use 'ethtool -S fiber1' to see how the packets gets
distributed across the rx and tx queues.
> CLONE_SKB="clone_skb 15"
Be careful with to high clone, as my experience is it will send a burst of
clone_skb packets before the packet gets randomized again.
> pgset "dst_min 192.168.0.2"
> pgset "dst_max 192.168.0.250"
> pgset "src_min 192.168.0.1"
> pgset "src_max 192.168.0.1"
> pgset "dst_mac 00:1b:21:4a:fe:55"
To get a packets randomized across RX queues, I used:
echo "- Random UDP source port min:$min - max:$max"
pgset "flag UDPSRC_RND"
pgset "udp_src_min $min"
pgset "udp_src_max $max"
Ahh.. I think you are missing:
pgset "flag IPDST_RND"
Cheers,
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
^ permalink raw reply
* Re: ixgbe question
From: Eric Dumazet @ 2009-11-23 14:05 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P; +Cc: Linux Netdev List
In-Reply-To: <4B0A65E0.7060403@gmail.com>
Eric Dumazet a écrit :
> Waskiewicz Jr, Peter P a écrit :
>> On Mon, 23 Nov 2009, Eric Dumazet wrote:
>>
>>> Hi Peter
>>>
>>> I tried a pktgen stress on 82599EB card and could not split RX load on multiple cpus.
>>>
>>> Setup is :
>>>
>>> One 82599 card with fiber0 looped to fiber1, 10Gb link mode.
>>> machine is a HPDL380 G6 with dual quadcore E5530 @2.4GHz (16 logical cpus)
>> Can you specify kernel version and driver version?
>
>
> Well, I forgot to mention I am only working with net-next-2.6 tree.
>
> Ubuntu 9.10 kernel (Fedora Core 12 installer was not able to recognize disks on this machine :( )
>
> ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 2.0.44-k2
>
>
I tried with several pktgen threads, no success so far.
Only one cpu handles all interrupts and ksoftirq enters
a mode with no escape to splitted mode.
To get real multi queue and uncontended handling, I had to force :
echo 1 >`echo /proc/irq/*/fiber1-TxRx-0/../smp_affinity`
echo 2 >`echo /proc/irq/*/fiber1-TxRx-1/../smp_affinity`
echo 4 >`echo /proc/irq/*/fiber1-TxRx-2/../smp_affinity`
echo 8 >`echo /proc/irq/*/fiber1-TxRx-3/../smp_affinity`
echo 10 >`echo /proc/irq/*/fiber1-TxRx-4/../smp_affinity`
echo 20 >`echo /proc/irq/*/fiber1-TxRx-5/../smp_affinity`
echo 40 >`echo /proc/irq/*/fiber1-TxRx-6/../smp_affinity`
echo 80 >`echo /proc/irq/*/fiber1-TxRx-7/../smp_affinity`
echo 100 >`echo /proc/irq/*/fiber1-TxRx-8/../smp_affinity`
echo 200 >`echo /proc/irq/*/fiber1-TxRx-9/../smp_affinity`
echo 400 >`echo /proc/irq/*/fiber1-TxRx-10/../smp_affinity`
echo 800 >`echo /proc/irq/*/fiber1-TxRx-11/../smp_affinity`
echo 1000 >`echo /proc/irq/*/fiber1-TxRx-12/../smp_affinity`
echo 2000 >`echo /proc/irq/*/fiber1-TxRx-13/../smp_affinity`
echo 4000 >`echo /proc/irq/*/fiber1-TxRx-14/../smp_affinity`
echo 8000 >`echo /proc/irq/*/fiber1-TxRx-15/../smp_affinity`
Probably problem comes from fact that when ksoftirqd runs and
RX queues are not depleted, no hardware interrupts is sent,
and NAPI contexts stay sticked on one cpu forever ?
^ permalink raw reply
* Re: Strange CPU load when flushing route cache (kernel 2.6.31.6)
From: Eric Dumazet @ 2009-11-23 14:03 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Jesper Dangaard Brouer, Linux Kernel Network Hackers,
Robert Olsson
In-Reply-To: <Pine.LNX.4.64.0911231437020.24347@ask.diku.dk>
> grep LowTotal /proc/meminfo
> LowTotal: 747080 kB
>
> What does that mean? Is it bad? What should I run on a 32-bit
> system/kernel?
If you have more than 1GB of physical ram, and use your machine as a router, you might
compile a 2GB/2GB User/Kernel kernel, to get twice available RAM for kernel
and more IP route entries (if needed)
make menuconfig
--> Processor type and features
--> Memory split
--> 2G/2G
> Can you recommend any other /proc/sys/ tuning options?
Really hard to say without exact context of use :)
>
> Does my kernel boot option rhash_entries=262143 make sense anymore?
> Or do we adjust the hash bucket size dynamically these days?
>
Its not dynamic yet.
^ permalink raw reply
* Re: Strange CPU load when flushing route cache (kernel 2.6.31.6)
From: Jesper Dangaard Brouer @ 2009-11-23 13:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesper Dangaard Brouer, Linux Kernel Network Hackers,
Robert Olsson
In-Reply-To: <4B0A8D41.6010608@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1870 bytes --]
On Mon, 23 Nov 2009, Eric Dumazet wrote:
> Jesper Dangaard Brouer a écrit :
>> On Mon, 2009-11-23 at 11:29 +0100, Eric Dumazet wrote:
>
>>> Sure, after a flush, we have to rebuild the cache, so extra work is expected.
>>
>> But the old 2.6.25.7 do NOT show this behavior... That is the real
>> issue...
>
> Previous kernels were crashing, because flush was immediate and not deferred
> as today.
>
> During flush, we were dropping enormous amounts of packets.
Ahh... Now I remember that was why I was flushing the cache so often. If
I flushed the route cache before it got too big then it was not a
problem with packet drops occuring.
> Now, its possible to have setups with equilibrium and no packet loss,
> because we smoothtly invalidate cache entries.
Which is a good thing :-)
>> I did the cache flushing due to some historical issues, that I think you
>> did a fix for... Guess I can drop the flushing and see if the garbage
>> collection can keep up...
>
> Yes it can. Unless your route cache settings are not optimal.
I'll adjust my flushing interval, or disable it and monitor it.
>>> Do you run a 2G/2G User/Kernel split kernel ?
>>
>> Not sure, how do I check?
>
> grep LowTotal /proc/meminfo
Yes, guess I'm using User/Kernel split.
grep LowTotal /proc/meminfo
LowTotal: 747080 kB
What does that mean? Is it bad? What should I run on a 32-bit
system/kernel?
Can you recommend any other /proc/sys/ tuning options?
Does my kernel boot option rhash_entries=262143 make sense anymore?
Or do we adjust the hash bucket size dynamically these days?
Cheers,
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 0/7] via-velocity performance fixes
From: Simon Kagstrom @ 2009-11-23 13:39 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem, davej, romieu
In-Reply-To: <20091120090348.1e51e29e@nehalam>
Hi Stephen and David!
Thanks for the comments, I'll address these in the next version.
On Fri, 20 Nov 2009 09:03:48 -0800
Stephen Hemminger <shemminger@vyatta.com> wrote:
> > 1. Correct setting of skipped checksums (unsure about this). The
> > mainline driver sets CHECKSUM_UNNECESSARY if this is an IP packet
> > except if the TCP checksum is NOT ok.
> >
> > The VIA driver sets CHECKSUM_UNNECESSARY if this is an UDP/TCP
> > packet except if the TCP checksum is not OK. The patch selects the
> > VIA behavior.
>
> The mainline driver is already doing the correct thing.
> The VIA driver would send packet
> with known bad checksum up the stack with CHECKSUM_UNNECESSARY.
> What is supposed to happen is:
>
> Checksum good: set CHECKSUM_UNNECESSARY
> bad: leave CHECKSUM_NONE
Yes, I see now that mainline is correct and I'll remove the patch from
the upcoming version 2 of the series. However, I don't think the driver
would send bad packets upwards - it would rather be more conservative.
What the current driver does is
ip_summed = CHECKSUM_NONE;
if (hardware sees that this is an IP packet):
if (hw IP checksum is OK):
if (hw sees that this is a TCP/UDP packet):
if (hw TCP/UDP checksum is NOT OK):
return # Returning CHECKSUM_NONE
ip_summed = CHECKSUM_UNNECESSARY
while the VIA driver does
ip_summed = CHECKSUM_NONE;
if (hardware sees that this is an IP packet):
if (hw IP checksum is OK):
if (hw sees that this is a TCP/UDP packet):
if (hw TCP/UDP checksum is NOT OK):
return # Returning CHECKSUM_NONE
ip_summed = CHECKSUM_UNNECESSARY
i.e., it will return CHECKSUM_NONE also for non-TCP/UDP IP packets.
// Simon
^ permalink raw reply
* Re: A generic kernel compatibilty code
From: Ben Hutchings @ 2009-11-23 13:26 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-kernel, linux-wireless, netdev
In-Reply-To: <43e72e890911201307g2a1f280aie223ed4fd270aad@mail.gmail.com>
On Fri, 2009-11-20 at 13:07 -0800, Luis R. Rodriguez wrote:
> On Fri, Nov 20, 2009 at 1:00 PM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
> > On Fri, 2009-11-20 at 12:45 -0800, Luis R. Rodriguez wrote:
> >> Everyone and their mother reinvents the wheel when it comes to
> >> backporting kernel modules. It a painful job and it seems to me an
> >> alternative is possible. If we can write generic compatibilty code for
> >> a new routine introduced on the next kernel how about just merging it
> >> to the kernel under some generic compat module. This would be
> >> completey ignored by everyone using the stable kernel but can be
> >> copied by anyone doing backport work.
> >>
> >> So I'm thinking something as simple as a generic compat/comat.ko with
> >> compat-2.6.32.[ch] files.
> >>
> >> We've already backported everything needed for wireless drivers under
> >> compat-wireless under this format down to even 2.6.25.
> > [...]
> >
> > If you think 2.6.25 is old then I don't think you understand the scale
> > of the problem.
> >
> > OEMs still expect us to support RHEL 4 (2.6.9) and SLES 9 (2.6.5) though
> > the latter will probably be dropped soon. Some other vendors apparently
> > still need to support even 2.4 kernels!
>
> Heh understood. Well shouldn't this help with that then? Sure I'd love
> to see the Enteprise Linux releases on 2.6.31 but that's not going to
> happen right? Shouldn't this help then?
You'd really have to ask the 'enterprise' vendors whether they'd be
interested in working on some sort of shared forward-compat library. If
the library is to include a module rather than being statically linked
into each module that needs it then there can only be one instance in
the system.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: Strange CPU load when flushing route cache (kernel 2.6.31.6)
From: Eric Dumazet @ 2009-11-23 13:25 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Linux Kernel Network Hackers, Robert Olsson
In-Reply-To: <1258979320.29747.270.camel@jdb-workstation>
Jesper Dangaard Brouer a écrit :
> On Mon, 2009-11-23 at 11:29 +0100, Eric Dumazet wrote:
>> Sure, after a flush, we have to rebuild the cache, so extra work is expected.
>
> But the old 2.6.25.7 do NOT show this behavior... That is the real
> issue...
Previous kernels were crashing, because flush was immediate and not deferred
as today.
During flush, we were dropping enormous amounts of packets.
Now, its possible to have setups with equilibrium and no packet loss,
because we smoothtly invalidate cache entries.
> I did the cache flushing due to some historical issues, that I think you
> did a fix for... Guess I can drop the flushing and see if the garbage
> collection can keep up...
Yes it can. Unless your route cache settings are not optimal.
>
>> Do you run a 2G/2G User/Kernel split kernel ?
>
> Not sure, how do I check?
grep LowTotal /proc/meminfo
or
dmesg | grep LOWMEM
913MB LOWMEM available. (standard 3G/1G User/Kernel split)
^ permalink raw reply
* RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Ben Hutchings @ 2009-11-23 13:22 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Kirsher, Jeffrey T, davem@davemloft.net, shemminger@vyatta.com,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FA6A200AD@rrsmsx501.amr.corp.intel.com>
On Thu, 2009-11-19 at 12:34 -0700, Williams, Mitch A wrote:
> >From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> >Sent: Thursday, November 19, 2009 10:59 AM
>
> >> Please explain specifically what you perceive to be the difference
> >between:
> >>
> >> $ ip link set eth1 queue 1 mac <blah>
> >> $ ip link set eth1 queue 1 vlan <foo>
> >>
> >> and
> >>
> >> $ ip link set eth1 queue 1 mac <blah> vlan <foo>
> >>
> >> The two filter types are, in my mind, completely orthogonal. You can
> >> have one, or the other, or both, or neither. What do we gain by
> >> glomming both options on one command line? And is this worth the
> >> tradeoff of more complex code?
> >
> >I think you need to state clearly what semantics you are now proposing
> >before I can make any judgement on them.
> >
>
> OK, now I'm really confused, Ben. It seems that we are both asking
> each other the same question.
>
> What I'm proposing is really the same as we have now for single-queue
> devices:
>
> - A MAC filter is enabled by default. If you want to change the MAC
> address, you use a tool (ip or ifconfig) to change it.
>
> - A VLAN filter is not enabled by default. If you want to filter on
> VLANs, then you load the 8021q module, and enable a filter.
This doesn't seem quite the same to me, but I'll not argue this.
> The MAC filter is configured completely separately from the VLAN
> filter. Either one can be changed without affecting the other one and,
> in fact, you use two different tools to do these operations.
>
> For SR-IOV VF devices, my proposed changes implement exactly the same
> thing. You use one command to change the MAC address. You use
> another command to change the VLAN filter. Changing one does not
> affect the other.
>
> In this case, we use the same tool for both operations, but they're
> still separate operations.
This makes some sense, and I accept that it's rather different from
filtering for delivery to the host.
> N.B.
> The major difference in VLAN filtering is that this implementation
> allows the VF to participate in only one VLAN, and the filter is
> applied independently of the VF driver. So you can put a specific VM
> on a VLAN without its knowledge. If you want the VM to have more
> intelligent VLAN filtering, you don't use this filter, and you load
> 8021q in the VM and set your filters there.
How does this interact with use of multiple queues within a single
function? Are the specified queue numbers really interpreted as RX
queue indices or as function numbers?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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
* Strange CPU load when flushing route cache (kernel 2.6.31.6)
From: robert @ 2009-11-23 15:07 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Eric Dumazet, Linux Kernel Network Hackers, Robert Olsson
In-Reply-To: <1258970332.29747.262.camel@jdb-workstation>
Jesper Dangaard Brouer writes:
> I have observed a strange route cache behaviour when I upgraded some
> of my production Linux routers (1Gbit/s tg3) to kernel 2.6.31.6 (from
> kernel 2.6.25.7).
>
> Every time the route cache is flushed I get a CPU spike (in softirq)
> with a tail. I have attached some graphs that illustrate the issue
> (hope vger.kernel.org will allow these attachments...)
Nice plots. Yes had the same problem long time. Packets were dropped on
even moderately loaded machines and the network managers were complaining.
Also the are some router benchmarks (RFC??) that estimates the forwarding
performance to the level when the first packet drop occurs. One can of course
discuss such test but it's there...
IMO is best to have he GC "inlined" with the creation of new flows and avoid
periodic tasks in this aspect.
Also I tried with something I called "active" garbage collection. The idea
was to get hints from TCP-FIN etc when to remove stale entries to take a
more pro-active approach. I think this was mentioned in the TRASH-paper.
If you only do routing you might try to disable the route cache.
Cheers
--ro
^ permalink raw reply
* netfilter: xt_limit: fix invalid return code in limit_mt_check()
From: Patrick McHardy @ 2009-11-23 12:43 UTC (permalink / raw)
To: David S. Miller; +Cc: Netfilter Development Mailinglist, Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 168 bytes --]
This patch fixes an invalid return value in the limit match.
Please apply or pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Thanks!
[-- Attachment #2: 01.diff --]
[-- Type: text/x-patch, Size: 805 bytes --]
commit 8fa539bd911e8a7faa7cd77b5192229c9666d9b8
Author: Patrick McHardy <kaber@trash.net>
Date: Mon Nov 23 13:37:23 2009 +0100
netfilter: xt_limit: fix invalid return code in limit_mt_check()
Commit acc738fe (netfilter: xtables: avoid pointer to self) introduced
an invalid return value in limit_mt_check().
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/xt_limit.c b/net/netfilter/xt_limit.c
index 2e8089e..2773be6 100644
--- a/net/netfilter/xt_limit.c
+++ b/net/netfilter/xt_limit.c
@@ -112,7 +112,7 @@ static bool limit_mt_check(const struct xt_mtchk_param *par)
priv = kmalloc(sizeof(*priv), GFP_KERNEL);
if (priv == NULL)
- return -ENOMEM;
+ return false;
/* For SMP, we only want to use one set of state. */
r->master = priv;
^ permalink raw reply related
* [PATCH] pktgen: Fix device name compares
From: robert @ 2009-11-23 14:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List, Robert Olsson
In-Reply-To: <4B0A75A5.8000106@gmail.com>
Eric Dumazet writes:
> Commit e6fce5b916cd7f7f7 (pktgen: multiqueue etc.) tried to relax
> the pktgen restriction of one device per kernel thread, adding a '@'
> tag to device names.
>
> Problem is we dont perform check on full pktgen device name.
> This allows adding many time same 'device' to pktgen thread
>
> pgset "add_device eth0@0"
>
> one session later :
>
> pgset "add_device eth0@0"
>
> (This doesnt find previous device)
> Solution to this problem is to use a odevname field (includes @ tag and suffix),
> instead of using netdevice name.
Ok. So the duplicate test got wrong when the multiqueue stuff was
added.
Signed-off-by: Robert Olsson <robert.olsson@its.uu.se>
Cheers
--ro
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/core/pktgen.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/net/core/pktgen.c b/net/core/pktgen.c
> index d38470a..1813f08 100644
> --- a/net/core/pktgen.c
> +++ b/net/core/pktgen.c
> @@ -364,6 +364,7 @@ struct pktgen_dev {
> * device name (not when the inject is
> * started as it used to do.)
> */
> + char odevname[32];
> struct flow_state *flows;
> unsigned cflows; /* Concurrent flows (config) */
> unsigned lflow; /* Flow length (config) */
> @@ -529,7 +530,7 @@ static int pktgen_if_show(struct seq_file *seq, void *v)
> seq_printf(seq,
> " frags: %d delay: %llu clone_skb: %d ifname: %s\n",
> pkt_dev->nfrags, (unsigned long long) pkt_dev->delay,
> - pkt_dev->clone_skb, pkt_dev->odev->name);
> + pkt_dev->clone_skb, pkt_dev->odevname);
>
> seq_printf(seq, " flows: %u flowlen: %u\n", pkt_dev->cflows,
> pkt_dev->lflow);
> @@ -1689,13 +1690,13 @@ static int pktgen_thread_show(struct seq_file *seq, void *v)
> if_lock(t);
> list_for_each_entry(pkt_dev, &t->if_list, list)
> if (pkt_dev->running)
> - seq_printf(seq, "%s ", pkt_dev->odev->name);
> + seq_printf(seq, "%s ", pkt_dev->odevname);
>
> seq_printf(seq, "\nStopped: ");
>
> list_for_each_entry(pkt_dev, &t->if_list, list)
> if (!pkt_dev->running)
> - seq_printf(seq, "%s ", pkt_dev->odev->name);
> + seq_printf(seq, "%s ", pkt_dev->odevname);
>
> if (t->result[0])
> seq_printf(seq, "\nResult: %s\n", t->result);
> @@ -1995,7 +1996,7 @@ static void pktgen_setup_inject(struct pktgen_dev *pkt_dev)
> "queue_map_min (zero-based) (%d) exceeds valid range "
> "[0 - %d] for (%d) queues on %s, resetting\n",
> pkt_dev->queue_map_min, (ntxq ?: 1) - 1, ntxq,
> - pkt_dev->odev->name);
> + pkt_dev->odevname);
> pkt_dev->queue_map_min = ntxq - 1;
> }
> if (pkt_dev->queue_map_max >= ntxq) {
> @@ -2003,7 +2004,7 @@ static void pktgen_setup_inject(struct pktgen_dev *pkt_dev)
> "queue_map_max (zero-based) (%d) exceeds valid range "
> "[0 - %d] for (%d) queues on %s, resetting\n",
> pkt_dev->queue_map_max, (ntxq ?: 1) - 1, ntxq,
> - pkt_dev->odev->name);
> + pkt_dev->odevname);
> pkt_dev->queue_map_max = ntxq - 1;
> }
>
> @@ -3263,7 +3264,7 @@ static int pktgen_stop_device(struct pktgen_dev *pkt_dev)
>
> if (!pkt_dev->running) {
> printk(KERN_WARNING "pktgen: interface: %s is already "
> - "stopped\n", pkt_dev->odev->name);
> + "stopped\n", pkt_dev->odevname);
> return -EINVAL;
> }
>
> @@ -3467,7 +3468,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
> default: /* Drivers are not supposed to return other values! */
> if (net_ratelimit())
> pr_info("pktgen: %s xmit error: %d\n",
> - odev->name, ret);
> + pkt_dev->odevname, ret);
> pkt_dev->errors++;
> /* fallthru */
> case NETDEV_TX_LOCKED:
> @@ -3576,7 +3577,7 @@ static struct pktgen_dev *pktgen_find_dev(struct pktgen_thread *t,
> if_lock(t);
>
> list_for_each_entry(p, &t->if_list, list)
> - if (strncmp(p->odev->name, ifname, IFNAMSIZ) == 0) {
> + if (strncmp(p->odevname, ifname, IFNAMSIZ) == 0) {
> pkt_dev = p;
> break;
> }
> @@ -3632,6 +3633,7 @@ static int pktgen_add_device(struct pktgen_thread *t, const char *ifname)
> if (!pkt_dev)
> return -ENOMEM;
>
> + strcpy(pkt_dev->odevname, ifname);
> pkt_dev->flows = vmalloc(MAX_CFLOWS * sizeof(struct flow_state));
> if (pkt_dev->flows == NULL) {
> kfree(pkt_dev);
^ permalink raw reply
* Re: Strange CPU load when flushing route cache (kernel 2.6.31.6)
From: Jesper Dangaard Brouer @ 2009-11-23 12:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Network Hackers, Robert Olsson
In-Reply-To: <4B0A63FA.5000804@gmail.com>
On Mon, 2009-11-23 at 11:29 +0100, Eric Dumazet wrote:
> Jesper Dangaard Brouer a écrit :
> > Hi Eric and netdev,
> >
> > I have observed a strange route cache behaviour when I upgraded some
> > of my production Linux routers (1Gbit/s tg3) to kernel 2.6.31.6 (from
> > kernel 2.6.25.7).
> >
> > Every time the route cache is flushed I get a CPU spike (in softirq)
> > with a tail. I have attached some graphs that illustrate the issue
> > (hope vger.kernel.org will allow these attachments...)
> >
> >
> > I have done some tuning of the route cache:
> >
> > # From /etc/sysctl.conf
> > #
> > # Adjusting the route cache flush interval
> > net/ipv4/route/secret_interval = 1200
> >
> > # Limiting the route cache size
> > # ip_dst_cache slab objects is 256 bytes.
> > # 2000000 * 256 bytes = 512 MB
> > net/ipv4/route/max_size = 2000000
> >
> > Boot parameters: "rhash_entries=262143 vmalloc=256M"
> >
> > The rhash_entries is for the route cache hash size. The vmalloc is
> > needed because I have _very_ large iptables rulesets (and is running
> > on a 32-bit kernel, due to old hardware).
> >
> > Any thoughs on how to avoid these CPU spikes?
> > Or where the issue occurs in the code?
> >
>
> Sure, after a flush, we have to rebuild the cache, so extra work is expected.
But the old 2.6.25.7 do NOT show this behavior... That is the real
issue...
> (We receive a packet, notice the cached entry is obsolete, free it, allocate a new one
> and inert it into cache)
>
> If you dont want these spikes, just dont flush cache :)
I did the cache flushing due to some historical issues, that I think you
did a fix for... Guess I can drop the flushing and see if the garbage
collection can keep up...
> Do you run a 2G/2G User/Kernel split kernel ?
Not sure, how do I check?
I do use a 32-bit kernel (due to the production machines runs an old
32-bit Slackware OS install and some of the machines cannot run 64-bit).
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network Kernel Developer
Cand. Scient Datalog / MSc.CS
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH] pktgen: Fix device name compares
From: Eric Dumazet @ 2009-11-23 11:44 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List, Robert Olsson
Commit e6fce5b916cd7f7f7 (pktgen: multiqueue etc.) tried to relax
the pktgen restriction of one device per kernel thread, adding a '@'
tag to device names.
Problem is we dont perform check on full pktgen device name.
This allows adding many time same 'device' to pktgen thread
pgset "add_device eth0@0"
one session later :
pgset "add_device eth0@0"
(This doesnt find previous device)
This consumes ~1.5 MBytes of vmalloc memory per round and also triggers
this warning :
[ 673.186380] proc_dir_entry 'pktgen/eth0@0' already registered
[ 673.186383] Modules linked in: pktgen ixgbe ehci_hcd psmouse mdio mousedev evdev [last unloaded: pktgen]
[ 673.186406] Pid: 6219, comm: bash Tainted: G W 2.6.32-rc7-03302-g41cec6f-dirty #16
[ 673.186410] Call Trace:
[ 673.186417] [<ffffffff8104a29b>] warn_slowpath_common+0x7b/0xc0
[ 673.186422] [<ffffffff8104a341>] warn_slowpath_fmt+0x41/0x50
[ 673.186426] [<ffffffff8114e789>] proc_register+0x109/0x210
[ 673.186433] [<ffffffff8100bf2e>] ? apic_timer_interrupt+0xe/0x20
[ 673.186438] [<ffffffff8114e905>] proc_create_data+0x75/0xd0
[ 673.186444] [<ffffffffa006ad38>] pktgen_thread_write+0x568/0x640 [pktgen]
[ 673.186449] [<ffffffffa006a7d0>] ? pktgen_thread_write+0x0/0x640 [pktgen]
[ 673.186453] [<ffffffff81149144>] proc_reg_write+0x84/0xc0
[ 673.186458] [<ffffffff810f5a58>] vfs_write+0xb8/0x180
[ 673.186463] [<ffffffff810f5c11>] sys_write+0x51/0x90
[ 673.186468] [<ffffffff8100b51b>] system_call_fastpath+0x16/0x1b
[ 673.186470] ---[ end trace ccbb991b0a8d994d ]---
Solution to this problem is to use a odevname field (includes @ tag and suffix),
instead of using netdevice name.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/pktgen.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index d38470a..1813f08 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -364,6 +364,7 @@ struct pktgen_dev {
* device name (not when the inject is
* started as it used to do.)
*/
+ char odevname[32];
struct flow_state *flows;
unsigned cflows; /* Concurrent flows (config) */
unsigned lflow; /* Flow length (config) */
@@ -529,7 +530,7 @@ static int pktgen_if_show(struct seq_file *seq, void *v)
seq_printf(seq,
" frags: %d delay: %llu clone_skb: %d ifname: %s\n",
pkt_dev->nfrags, (unsigned long long) pkt_dev->delay,
- pkt_dev->clone_skb, pkt_dev->odev->name);
+ pkt_dev->clone_skb, pkt_dev->odevname);
seq_printf(seq, " flows: %u flowlen: %u\n", pkt_dev->cflows,
pkt_dev->lflow);
@@ -1689,13 +1690,13 @@ static int pktgen_thread_show(struct seq_file *seq, void *v)
if_lock(t);
list_for_each_entry(pkt_dev, &t->if_list, list)
if (pkt_dev->running)
- seq_printf(seq, "%s ", pkt_dev->odev->name);
+ seq_printf(seq, "%s ", pkt_dev->odevname);
seq_printf(seq, "\nStopped: ");
list_for_each_entry(pkt_dev, &t->if_list, list)
if (!pkt_dev->running)
- seq_printf(seq, "%s ", pkt_dev->odev->name);
+ seq_printf(seq, "%s ", pkt_dev->odevname);
if (t->result[0])
seq_printf(seq, "\nResult: %s\n", t->result);
@@ -1995,7 +1996,7 @@ static void pktgen_setup_inject(struct pktgen_dev *pkt_dev)
"queue_map_min (zero-based) (%d) exceeds valid range "
"[0 - %d] for (%d) queues on %s, resetting\n",
pkt_dev->queue_map_min, (ntxq ?: 1) - 1, ntxq,
- pkt_dev->odev->name);
+ pkt_dev->odevname);
pkt_dev->queue_map_min = ntxq - 1;
}
if (pkt_dev->queue_map_max >= ntxq) {
@@ -2003,7 +2004,7 @@ static void pktgen_setup_inject(struct pktgen_dev *pkt_dev)
"queue_map_max (zero-based) (%d) exceeds valid range "
"[0 - %d] for (%d) queues on %s, resetting\n",
pkt_dev->queue_map_max, (ntxq ?: 1) - 1, ntxq,
- pkt_dev->odev->name);
+ pkt_dev->odevname);
pkt_dev->queue_map_max = ntxq - 1;
}
@@ -3263,7 +3264,7 @@ static int pktgen_stop_device(struct pktgen_dev *pkt_dev)
if (!pkt_dev->running) {
printk(KERN_WARNING "pktgen: interface: %s is already "
- "stopped\n", pkt_dev->odev->name);
+ "stopped\n", pkt_dev->odevname);
return -EINVAL;
}
@@ -3467,7 +3468,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
default: /* Drivers are not supposed to return other values! */
if (net_ratelimit())
pr_info("pktgen: %s xmit error: %d\n",
- odev->name, ret);
+ pkt_dev->odevname, ret);
pkt_dev->errors++;
/* fallthru */
case NETDEV_TX_LOCKED:
@@ -3576,7 +3577,7 @@ static struct pktgen_dev *pktgen_find_dev(struct pktgen_thread *t,
if_lock(t);
list_for_each_entry(p, &t->if_list, list)
- if (strncmp(p->odev->name, ifname, IFNAMSIZ) == 0) {
+ if (strncmp(p->odevname, ifname, IFNAMSIZ) == 0) {
pkt_dev = p;
break;
}
@@ -3632,6 +3633,7 @@ static int pktgen_add_device(struct pktgen_thread *t, const char *ifname)
if (!pkt_dev)
return -ENOMEM;
+ strcpy(pkt_dev->odevname, ifname);
pkt_dev->flows = vmalloc(MAX_CFLOWS * sizeof(struct flow_state));
if (pkt_dev->flows == NULL) {
kfree(pkt_dev);
^ permalink raw reply related
* Re: [net-next-2.6 PATCH v7 5/7 RFC] TCPCT part 1e: implement socket option TCP_COOKIE_TRANSACTIONS
From: William Allen Simpson @ 2009-11-23 11:16 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, netdev
In-Reply-To: <1258873848.16503.12.camel@Joe-Laptop.home>
Joe Perches wrote:
> On Sun, 2009-11-22 at 01:25 -0500, William Allen Simpson wrote:
>> David Miller wrote:
>>> From: William Allen Simpson <william.allen.simpson@gmail.com>
>>> Date: Fri, 20 Nov 2009 09:48:12 -0500
>>>> + if (ctd.tcpct_used > 0
>>>> + || (tp->cookie_values == NULL
>>>> + && (sysctl_tcp_cookie_size > 0
>>>> + || ctd.tcpct_cookie_desired > 0
>>>> + || ctd.tcpct_s_data_desired > 0))) {
>>> Please fix the conditional coding style, and the alignment of
>>> the lines, it's not right here.
>
> I think the rather significantly majority style, especially
> for net/... is to use || and && at the end of the line rather
> than the start and it should be used.
>
> Treewide:
>
> $ grep -rP --include=*.[ch] "(\|\||\&\&)\s*$" * | wc -l
> 34180
>
> $ grep -rP --include=*.[ch] "^\s*(\|\||\&\&)" * | wc -l
> 7855
>
> net: 3859 to 382 (more than 10:1, so it's the one to follow)
> drivers/net: 4610 to 666
>
Thanks for measuring.
I'll note that during the previous review back at the v4 round, you
(Joe) passed along a formerly private message from Linus expressing his
preference for variable lvalues:
http://www.spinics.net/lists/netdev/msg111212.html
But my example code in that thread also had both leading && and || -- and
neither David nor Eric nor Ilpo nor you mentioned that as an issue in that
entire thread:
http://www.spinics.net/lists/netdev/msg111172.html
In the previous plaint about lvalues, there were merely 500+ examples
using the same constant lvalue form as my code -- in arch, drivers, net,
and sound. For this example, many *thousands* are found everywhere!
Therefore, it's plain as can be that this is just more jumping through
arbitrary and capricious hoops that others are not required to follow.
> Besides, it's the one David wants...
>
At *thousands* of examples, including in the tcp*.c files themselves, it
really becomes obvious that that may be a personal preference of David,
but is *not* a tree-wide or even a net-wide coding style.
However, a private message to me nearly 2 months ago expressed:
"As unpalatable as it may be, all the more reason to genuflect as
required to get the changes into the net-next-2.6 tree so they will
flow down to future distros."
I followed that advice for a month. That last patch submitted for
inclusion was v4 on Oct 27th. Then, as some have noticed, I quit using
the net-next tree for actual development. I've only sent weekly RFC
versions to solicit more widespread comments from subject matter experts,
and keep the patch offsets in sync with the rapidly changing tree.
As a more recent private comment asked:
"So your frustration is nothing but normal. And guess what ? Few
people accept the challenge, so keep trying !"
So, I'll try again now, with the assurance that this is the final hoop.
^ permalink raw reply
* Re: Request for help with iproute2 bugs.
From: Patrick McHardy @ 2009-11-23 11:03 UTC (permalink / raw)
To: Andreas Henriksson; +Cc: netdev, shemminger
In-Reply-To: <20091123103742.GA14713@amd64.fatal.se>
[-- Attachment #1: Type: text/plain, Size: 200 bytes --]
Andreas Henriksson wrote:
> http://bugs.debian.org/532727
> iproute: "tc filter add ... protocol ip fw" broken?
>
This one is caused by a regression in iproute2. The attached patch
should fix it.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1640 bytes --]
commit b3d80773099c13f60598857901cb2724c210614f
Author: Patrick McHardy <kaber@trash.net>
Date: Mon Nov 23 12:00:46 2009 +0100
f_fw: fix compat mode
The kernel takes a lack of options as indication that the fw classifier
should operate in compatibility mode, where marks are mapped directly to
classids.
Commit e22b42a (tc mask patch) broke this by adding an empty TCA_OPTIONS
attribute even if no handle is specified. Restore the old behaviour.
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/tc/f_fw.c b/tc/f_fw.c
index b511735..cc8ea2d 100644
--- a/tc/f_fw.c
+++ b/tc/f_fw.c
@@ -38,15 +38,13 @@ static int fw_parse_opt(struct filter_util *qu, char *handle, int argc, char **a
struct tc_police tp;
struct tcmsg *t = NLMSG_DATA(n);
struct rtattr *tail;
+ __u32 mask = 0;
+ int mask_set = 0;
memset(&tp, 0, sizeof(tp));
- tail = NLMSG_TAIL(n);
- addattr_l(n, 4096, TCA_OPTIONS, NULL, 0);
-
if (handle) {
char *slash;
- __u32 mask = 0;
if ((slash = strchr(handle, '/')) != NULL)
*slash = '\0';
if (get_u32(&t->tcm_handle, handle, 0)) {
@@ -58,13 +56,19 @@ static int fw_parse_opt(struct filter_util *qu, char *handle, int argc, char **a
fprintf(stderr, "Illegal \"handle\" mask\n");
return -1;
}
- addattr32(n, MAX_MSG, TCA_FW_MASK, mask);
+ mask_set = 1;
}
}
if (argc == 0)
return 0;
+ tail = NLMSG_TAIL(n);
+ addattr_l(n, 4096, TCA_OPTIONS, NULL, 0);
+
+ if (mask_set)
+ addattr32(n, MAX_MSG, TCA_FW_MASK, mask);
+
while (argc > 0) {
if (matches(*argv, "classid") == 0 ||
matches(*argv, "flowid") == 0) {
^ permalink raw reply related
* Buy 1, get 2 for free
From: Caroline Rangel @ 2009-11-23 10:56 UTC (permalink / raw)
To: netdev
Perfect proportions are easily to get . http://vxre.pointinvent.com/
^ permalink raw reply
* Request for help with iproute2 bugs.
From: Andreas Henriksson @ 2009-11-23 10:37 UTC (permalink / raw)
To: netdev; +Cc: shemminger
Hello everybody!
This is a desperate attempt at finding people with time and motivation
to look into bugs that has been reported against the iproute package
in the debian bug tracking system. The reported bugs are usually
not Debian-specific...
You'll find the complete list at http://bugs.debian.org/iproute
If you have comments, please email them to <bugnumber>@bugs.debian.org
Here's a list of interesting candidates, hopefully you'll find some useful
comments if you follow the link (usually last comment at the bottom):
http://bugs.debian.org/532152 - incorrectly enumerates existing addresses.
iproute: 'ip addr flush' exits with error on first try
http://bugs.debian.org/525933 - many ip-addresses not handled gracefully.
iproute: "ip address" failes to list all IPs on an interface
http://bugs.debian.org/511720 - rip out flawed code in favor of sed ?
iproute: ss filter parsing flawed
http://bugs.debian.org/532727
iproute: "tc filter add ... protocol ip fw" broken?
http://bugs.debian.org/551937 - replacing ipv6 routes broken.
iproute: "ip -6 route replace ..." behaves as "ip -6 route add ..."
http://bugs.debian.org/498498 - ipv6 specific blackhole routing.
iproute: adding route blackholes doesn't work for IPv6
http://bugs.debian.org/508450 - weird behaviour confuses users.
ip tun add fails to create tunnel without remote, though no error
--
Andreas Henriksson
^ permalink raw reply
* Re: ixgbe question
From: Eric Dumazet @ 2009-11-23 10:37 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P; +Cc: Linux Netdev List
In-Reply-To: <Pine.WNT.4.64.0911230225140.6352@ppwaskie-MOBL2.amr.corp.intel.com>
Waskiewicz Jr, Peter P a écrit :
> On Mon, 23 Nov 2009, Eric Dumazet wrote:
>
>> Hi Peter
>>
>> I tried a pktgen stress on 82599EB card and could not split RX load on multiple cpus.
>>
>> Setup is :
>>
>> One 82599 card with fiber0 looped to fiber1, 10Gb link mode.
>> machine is a HPDL380 G6 with dual quadcore E5530 @2.4GHz (16 logical cpus)
>
> Can you specify kernel version and driver version?
Well, I forgot to mention I am only working with net-next-2.6 tree.
Ubuntu 9.10 kernel (Fedora Core 12 installer was not able to recognize disks on this machine :( )
ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 2.0.44-k2
>
>> I use one pktgen thread sending to fiber0 one many dst IP, and checked that fiber1
>> was using many RX queues :
>>
>> grep fiber1 /proc/interrupts
>> 117: 1301 13060 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-0
>> 118: 601 1402 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-1
>> 119: 634 832 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-2
>> 120: 601 1303 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-3
>> 121: 620 1246 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-4
>> 122: 1287 13088 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-5
>> 123: 606 1354 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-6
>> 124: 653 827 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-7
>> 125: 639 825 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-8
>> 126: 596 1199 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-9
>> 127: 2013 24800 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-10
>> 128: 648 1353 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-11
>> 129: 601 1123 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-12
>> 130: 625 834 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-13
>> 131: 665 1409 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-14
>> 132: 2637 31699 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-15
>> 133: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1:lsc
>>
>>
>>
>> But only one CPU (CPU1) had a softirq running, 100%, and many frames were dropped
>>
>> root@demodl380g6:/usr/src# ifconfig fiber0
>> fiber0 Link encap:Ethernet HWaddr 00:1b:21:4a:fe:54
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> Packets reçus:4 erreurs:0 :0 overruns:0 frame:0
>> TX packets:309291576 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 lg file transmission:1000
>> Octets reçus:1368 (1.3 KB) Octets transmis:18557495682 (18.5 GB)
>>
>> root@demodl380g6:/usr/src# ifconfig fiber1
>> fiber1 Link encap:Ethernet HWaddr 00:1b:21:4a:fe:55
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> Packets reçus:55122164 erreurs:0 :254169411 overruns:0 frame:0
>> TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 lg file transmission:1000
>> Octets reçus:3307330968 (3.3 GB) Octets transmis:1368 (1.3 KB)
>
> I stay in the states too much. I love seeing net stats in French. :-)
Ok :)
>
>>
>> How and when multi queue rx can really start to use several cpus ?
>
> If you're sending one flow to many consumers, it's still one flow. Even
> using RSS won't help, since it requires differing flows to spread load
> (5-tuple matches for flow distribution).
Hm... I can try varying both src and dst on my pktgen test.
Thanks
^ permalink raw reply
* Re: ixgbe question
From: Waskiewicz Jr, Peter P @ 2009-11-23 10:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Waskiewicz Jr, Peter P, Linux Netdev List
In-Reply-To: <4B0A6218.9040303@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5581 bytes --]
On Mon, 23 Nov 2009, Eric Dumazet wrote:
> Hi Peter
>
> I tried a pktgen stress on 82599EB card and could not split RX load on multiple cpus.
>
> Setup is :
>
> One 82599 card with fiber0 looped to fiber1, 10Gb link mode.
> machine is a HPDL380 G6 with dual quadcore E5530 @2.4GHz (16 logical cpus)
Can you specify kernel version and driver version?
>
> I use one pktgen thread sending to fiber0 one many dst IP, and checked that fiber1
> was using many RX queues :
>
> grep fiber1 /proc/interrupts
> 117: 1301 13060 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-0
> 118: 601 1402 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-1
> 119: 634 832 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-2
> 120: 601 1303 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-3
> 121: 620 1246 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-4
> 122: 1287 13088 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-5
> 123: 606 1354 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-6
> 124: 653 827 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-7
> 125: 639 825 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-8
> 126: 596 1199 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-9
> 127: 2013 24800 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-10
> 128: 648 1353 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-11
> 129: 601 1123 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-12
> 130: 625 834 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-13
> 131: 665 1409 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-14
> 132: 2637 31699 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-15
> 133: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1:lsc
>
>
>
> But only one CPU (CPU1) had a softirq running, 100%, and many frames were dropped
>
> root@demodl380g6:/usr/src# ifconfig fiber0
> fiber0 Link encap:Ethernet HWaddr 00:1b:21:4a:fe:54
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> Packets reçus:4 erreurs:0 :0 overruns:0 frame:0
> TX packets:309291576 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 lg file transmission:1000
> Octets reçus:1368 (1.3 KB) Octets transmis:18557495682 (18.5 GB)
>
> root@demodl380g6:/usr/src# ifconfig fiber1
> fiber1 Link encap:Ethernet HWaddr 00:1b:21:4a:fe:55
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> Packets reçus:55122164 erreurs:0 :254169411 overruns:0 frame:0
> TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 lg file transmission:1000
> Octets reçus:3307330968 (3.3 GB) Octets transmis:1368 (1.3 KB)
I stay in the states too much. I love seeing net stats in French. :-)
>
>
> How and when multi queue rx can really start to use several cpus ?
If you're sending one flow to many consumers, it's still one flow. Even
using RSS won't help, since it requires differing flows to spread load
(5-tuple matches for flow distribution).
Cheers,
-PJ
^ permalink raw reply
* macvlan: fix gso_max_size setting
From: Patrick McHardy @ 2009-11-23 10:33 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 62 bytes --]
Fix macvlan gso_max_size setting. Based on net-next-2.6.git.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1184 bytes --]
commit 198a1fd488e7ebec080d1d2da7947cb9e1aacebf
Author: Patrick McHardy <kaber@trash.net>
Date: Mon Nov 23 11:28:22 2009 +0100
macvlan: fix gso_max_size setting
gso_max_size must be set based on the value of the underlying device to
support devices not using the full 64k.
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index ae2b5c7..7b0ef0c 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -376,6 +376,7 @@ static int macvlan_init(struct net_device *dev)
dev->state = (dev->state & ~MACVLAN_STATE_MASK) |
(lowerdev->state & MACVLAN_STATE_MASK);
dev->features = lowerdev->features & MACVLAN_FEATURES;
+ dev->gso_max_size = lowerdev->gso_max_size;
dev->iflink = lowerdev->ifindex;
dev->hard_header_len = lowerdev->hard_header_len;
@@ -652,6 +653,7 @@ static int macvlan_device_event(struct notifier_block *unused,
case NETDEV_FEAT_CHANGE:
list_for_each_entry(vlan, &port->vlans, list) {
vlan->dev->features = dev->features & MACVLAN_FEATURES;
+ vlan->dev->gso_max_size = dev->gso_max_size;
netdev_features_change(vlan->dev);
}
break;
^ permalink raw reply related
* Re: ixgbe question
From: Badalian Vyacheslav @ 2009-11-23 10:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Peter P Waskiewicz Jr, Linux Netdev List
In-Reply-To: <4B0A6218.9040303@gmail.com>
Hello Eric. I paly with this card 3 weeks and maybe help for you :)
By default intel flower use only first cpu. Its strange.
If we add affinity to single cpu core for interrupt its will use this CPU core.
If we add affinity to two or more cpus its applying but don't work.
See ixgbe driver README from intel.com. Its have param for RSS flower. I think its do this :)
Also driver from intel.com have script for split RxTx->Cpu core but you must replace "tx rx" in code to "TxRx".
P.S. Please also see if you can and wont:
On e1000 and x86 kernel + 2xXeon 2core my TC rules load 3 min
On ixgbe and X86_64 kernel + 4xXeon 6core my TC rules load more 15 mins!
Its 64 bit regression?
Tc rules i can send to you if you ask me for it! Thanks!
Slavon
> Hi Peter
>
> I tried a pktgen stress on 82599EB card and could not split RX load on multiple cpus.
>
> Setup is :
>
> One 82599 card with fiber0 looped to fiber1, 10Gb link mode.
> machine is a HPDL380 G6 with dual quadcore E5530 @2.4GHz (16 logical cpus)
>
> I use one pktgen thread sending to fiber0 one many dst IP, and checked that fiber1
> was using many RX queues :
>
> grep fiber1 /proc/interrupts
> 117: 1301 13060 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-0
> 118: 601 1402 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-1
> 119: 634 832 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-2
> 120: 601 1303 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-3
> 121: 620 1246 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-4
> 122: 1287 13088 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-5
> 123: 606 1354 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-6
> 124: 653 827 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-7
> 125: 639 825 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-8
> 126: 596 1199 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-9
> 127: 2013 24800 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-10
> 128: 648 1353 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-11
> 129: 601 1123 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-12
> 130: 625 834 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-13
> 131: 665 1409 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-14
> 132: 2637 31699 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1-TxRx-15
> 133: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge fiber1:lsc
>
>
>
> But only one CPU (CPU1) had a softirq running, 100%, and many frames were dropped
>
> root@demodl380g6:/usr/src# ifconfig fiber0
> fiber0 Link encap:Ethernet HWaddr 00:1b:21:4a:fe:54
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> Packets reçus:4 erreurs:0 :0 overruns:0 frame:0
> TX packets:309291576 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 lg file transmission:1000
> Octets reçus:1368 (1.3 KB) Octets transmis:18557495682 (18.5 GB)
>
> root@demodl380g6:/usr/src# ifconfig fiber1
> fiber1 Link encap:Ethernet HWaddr 00:1b:21:4a:fe:55
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> Packets reçus:55122164 erreurs:0 :254169411 overruns:0 frame:0
> TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 lg file transmission:1000
> Octets reçus:3307330968 (3.3 GB) Octets transmis:1368 (1.3 KB)
>
>
> How and when multi queue rx can really start to use several cpus ?
>
> Thanks
> Eric
>
>
> pktgen script :
>
> pgset()
> {
> local result
>
> echo $1 > $PGDEV
>
> result=`cat $PGDEV | fgrep "Result: OK:"`
> if [ "$result" = "" ]; then
> cat $PGDEV | fgrep Result:
> fi
> }
>
> pg()
> {
> echo inject > $PGDEV
> cat $PGDEV
> }
>
>
> PGDEV=/proc/net/pktgen/kpktgend_4
>
> echo "Adding fiber0"
> pgset "add_device fiber0@0"
>
>
> CLONE_SKB="clone_skb 15"
>
> PKT_SIZE="pkt_size 60"
>
>
> COUNT="count 100000000"
> DELAY="delay 0"
>
> PGDEV=/proc/net/pktgen/fiber0@0
> echo "Configuring $PGDEV"
> pgset "$COUNT"
> pgset "$CLONE_SKB"
> pgset "$PKT_SIZE"
> pgset "$DELAY"
> pgset "queue_map_min 0"
> pgset "queue_map_max 7"
> pgset "dst_min 192.168.0.2"
> pgset "dst_max 192.168.0.250"
> pgset "src_min 192.168.0.1"
> pgset "src_max 192.168.0.1"
> pgset "dst_mac 00:1b:21:4a:fe:55"
>
>
> # Time to run
> PGDEV=/proc/net/pktgen/pgctrl
>
> echo "Running... ctrl^C to stop"
> pgset "start"
> echo "Done"
>
> # Result can be vieved in /proc/net/pktgen/fiber0@0
>
> for f in fiber0@0
> do
> cat /proc/net/pktgen/$f
> done
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ 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