* Re: [PATCH] net: b43legacy: fix compile error
From: Eric Dumazet @ 2010-10-25 15:51 UTC (permalink / raw)
To: Larry Finger
Cc: Arnd Hannemann, David S. Miller, netdev, linux-kernel,
linux-wireless
In-Reply-To: <4CC5A301.1080606@lwfinger.net>
Le lundi 25 octobre 2010 à 10:32 -0500, Larry Finger a écrit :
> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
> > On todays linus tree the following compile error happened to me:
> >
> > CC [M] drivers/net/wireless/b43legacy/xmit.o
> > In file included from include/net/dst.h:11,
> > from drivers/net/wireless/b43legacy/xmit.c:31:
> > include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
> > include/net/dst_ops.h: In function 'dst_entries_get_fast':
> > include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> > include/net/dst_ops.h: In function 'dst_entries_get_slow':
> > include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> > include/net/dst_ops.h: In function 'dst_entries_add':
> > include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> > include/net/dst_ops.h: In function 'dst_entries_init':
> > include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> > include/net/dst_ops.h: In function 'dst_entries_destroy':
> > include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> > make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
> > make[3]: *** [drivers/net/wireless/b43legacy] Error 2
> > make[2]: *** [drivers/net/wireless] Error 2
> > make[1]: *** [drivers/net] Error 2
> > make: *** [drivers] Error 2
> >
> > This patch fixes this issue by adding "linux/cache.h" as an include to
> > "include/net/dst_ops.h".
>
> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
Well, x86_64 must include cache.h, this is probably why I missed it in
my build tests.
I wonder also why #include <net/dst.h> is needed at all in this
driver...
diff --git a/drivers/net/wireless/b43legacy/xmit.c
b/drivers/net/wireless/b43legacy/xmit.c
index 7d177d9..a261aec 100644
--- a/drivers/net/wireless/b43legacy/xmit.c
+++ b/drivers/net/wireless/b43legacy/xmit.c
@@ -28,8 +28,6 @@
*/
-#include <net/dst.h>
-
#include "xmit.h"
#include "phy.h"
#include "dma.h"
^ permalink raw reply related
* Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
From: Michael S. Tsirkin @ 2010-10-25 16:17 UTC (permalink / raw)
To: Krishna Kumar2
Cc: anthony, arnd, avi, davem, eric.dumazet, kvm, netdev, rusty
In-Reply-To: <OF8735A2A4.74B4EE91-ON652577C5.0040D90B-652577C7.0056B99D@in.ibm.com>
On Mon, Oct 25, 2010 at 09:20:38PM +0530, Krishna Kumar2 wrote:
> > Krishna Kumar2/India/IBM@IBMIN wrote on 10/20/2010 02:24:52 PM:
>
> Any feedback, comments, objections, issues or bugs about the
> patches? Please let me know if something needs to be done.
I am trying to wrap my head around kernel/user interface here.
E.g., will we need another incompatible change when we add multiple RX
queues? Also need to think about how robust our single stream heuristic is,
e.g. what are the chances it will misdetect a bidirectional
UDP stream as a single TCP?
> Some more test results:
> _____________________________________________________
> Host->Guest BW (numtxqs=2)
> # BW% CPU% RCPU% SD% RSD%
> _____________________________________________________
> 1 5.53 .31 .67 -5.88 0
> 2 -2.11 -1.01 -2.08 4.34 0
> 4 13.53 10.77 13.87 -1.96 0
> 8 34.22 22.80 30.53 -8.46 -2.50
> 16 30.89 24.06 35.17 -5.20 3.20
> 24 33.22 26.30 43.39 -5.17 7.58
> 32 30.85 27.27 47.74 -.59 15.51
> 40 33.80 27.33 48.00 -7.42 7.59
> 48 45.93 26.33 45.46 -12.24 1.10
> 64 33.51 27.11 45.00 -3.27 10.30
> 80 39.28 29.21 52.33 -4.88 12.17
> 96 32.05 31.01 57.72 -1.02 19.05
> 128 35.66 32.04 60.00 -.66 20.41
> _____________________________________________________
> BW: 23.5% CPU/RCPU: 28.6%,51.2% SD/RSD: -2.6%,15.8%
>
> ____________________________________________________
> Guest->Host 512 byte (numtxqs=2):
> # BW% CPU% RCPU% SD% RSD%
> _____________________________________________________
> 1 3.02 -3.84 -4.76 -12.50 -7.69
> 2 52.77 -15.73 -8.66 -45.31 -40.33
> 4 -23.14 13.84 7.50 50.58 40.81
> 8 -21.44 28.08 16.32 63.06 47.43
> 16 33.53 46.50 27.19 7.61 -6.60
> 24 55.77 42.81 30.49 -8.65 -16.48
> 32 52.59 38.92 29.08 -9.18 -15.63
> 40 50.92 36.11 28.92 -10.59 -15.30
> 48 46.63 34.73 28.17 -7.83 -12.32
> 64 45.56 37.12 28.81 -5.05 -10.80
> 80 44.55 36.60 28.45 -4.95 -10.61
> 96 43.02 35.97 28.89 -.11 -5.31
> 128 38.54 33.88 27.19 -4.79 -9.54
> _____________________________________________________
> BW: 34.4% CPU/RCPU: 35.9%,27.8% SD/RSD: -4.1%,-9.3%
>
>
> Thanks,
>
> - KK
>
>
>
> > [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
> >
> > Following set of patches implement transmit MQ in virtio-net. Also
> > included is the user qemu changes. MQ is disabled by default unless
> > qemu specifies it.
> >
> > Changes from rev2:
> > ------------------
> > 1. Define (in virtio_net.h) the maximum send txqs; and use in
> > virtio-net and vhost-net.
> > 2. vi->sq[i] is allocated individually, resulting in cache line
> > aligned sq[0] to sq[n]. Another option was to define
> > 'send_queue' as:
> > struct send_queue {
> > struct virtqueue *svq;
> > struct scatterlist tx_sg[MAX_SKB_FRAGS + 2];
> > } ____cacheline_aligned_in_smp;
> > and to statically allocate 'VIRTIO_MAX_SQ' of those. I hope
> > the submitted method is preferable.
> > 3. Changed vhost model such that vhost[0] handles RX and vhost[1-MAX]
> > handles TX[0-n].
> > 4. Further change TX handling such that vhost[0] handles both RX/TX
> > for single stream case.
> >
> > Enabling MQ on virtio:
> > -----------------------
> > When following options are passed to qemu:
> > - smp > 1
> > - vhost=on
> > - mq=on (new option, default:off)
> > then #txqueues = #cpus. The #txqueues can be changed by using an
> > optional 'numtxqs' option. e.g. for a smp=4 guest:
> > vhost=on -> #txqueues = 1
> > vhost=on,mq=on -> #txqueues = 4
> > vhost=on,mq=on,numtxqs=2 -> #txqueues = 2
> > vhost=on,mq=on,numtxqs=8 -> #txqueues = 8
> >
> >
> > Performance (guest -> local host):
> > -----------------------------------
> > System configuration:
> > Host: 8 Intel Xeon, 8 GB memory
> > Guest: 4 cpus, 2 GB memory
> > Test: Each test case runs for 60 secs, sum over three runs (except
> > when number of netperf sessions is 1, which has 10 runs of 12 secs
> > each). No tuning (default netperf) other than taskset vhost's to
> > cpus 0-3. numtxqs=32 gave the best results though the guest had
> > only 4 vcpus (I haven't tried beyond that).
> >
> > ______________ numtxqs=2, vhosts=3 ____________________
> > #sessions BW% CPU% RCPU% SD% RSD%
> > ________________________________________________________
> > 1 4.46 -1.96 .19 -12.50 -6.06
> > 2 4.93 -1.16 2.10 0 -2.38
> > 4 46.17 64.77 33.72 19.51 -2.48
> > 8 47.89 70.00 36.23 41.46 13.35
> > 16 48.97 80.44 40.67 21.11 -5.46
> > 24 49.03 78.78 41.22 20.51 -4.78
> > 32 51.11 77.15 42.42 15.81 -6.87
> > 40 51.60 71.65 42.43 9.75 -8.94
> > 48 50.10 69.55 42.85 11.80 -5.81
> > 64 46.24 68.42 42.67 14.18 -3.28
> > 80 46.37 63.13 41.62 7.43 -6.73
> > 96 46.40 63.31 42.20 9.36 -4.78
> > 128 50.43 62.79 42.16 13.11 -1.23
> > ________________________________________________________
> > BW: 37.2%, CPU/RCPU: 66.3%,41.6%, SD/RSD: 11.5%,-3.7%
> >
> > ______________ numtxqs=8, vhosts=5 ____________________
> > #sessions BW% CPU% RCPU% SD% RSD%
> > ________________________________________________________
> > 1 -.76 -1.56 2.33 0 3.03
> > 2 17.41 11.11 11.41 0 -4.76
> > 4 42.12 55.11 30.20 19.51 .62
> > 8 54.69 80.00 39.22 24.39 -3.88
> > 16 54.77 81.62 40.89 20.34 -6.58
> > 24 54.66 79.68 41.57 15.49 -8.99
> > 32 54.92 76.82 41.79 17.59 -5.70
> > 40 51.79 68.56 40.53 15.31 -3.87
> > 48 51.72 66.40 40.84 9.72 -7.13
> > 64 51.11 63.94 41.10 5.93 -8.82
> > 80 46.51 59.50 39.80 9.33 -4.18
> > 96 47.72 57.75 39.84 4.20 -7.62
> > 128 54.35 58.95 40.66 3.24 -8.63
> > ________________________________________________________
> > BW: 38.9%, CPU/RCPU: 63.0%,40.1%, SD/RSD: 6.0%,-7.4%
> >
> > ______________ numtxqs=16, vhosts=5 ___________________
> > #sessions BW% CPU% RCPU% SD% RSD%
> > ________________________________________________________
> > 1 -1.43 -3.52 1.55 0 3.03
> > 2 33.09 21.63 20.12 -10.00 -9.52
> > 4 67.17 94.60 44.28 19.51 -11.80
> > 8 75.72 108.14 49.15 25.00 -10.71
> > 16 80.34 101.77 52.94 25.93 -4.49
> > 24 70.84 93.12 43.62 27.63 -5.03
> > 32 69.01 94.16 47.33 29.68 -1.51
> > 40 58.56 63.47 25.91 -3.92 -25.85
> > 48 61.16 74.70 34.88 .89 -22.08
> > 64 54.37 69.09 26.80 -6.68 -30.04
> > 80 36.22 22.73 -2.97 -8.25 -27.23
> > 96 41.51 50.59 13.24 9.84 -16.77
> > 128 48.98 38.15 6.41 -.33 -22.80
> > ________________________________________________________
> > BW: 46.2%, CPU/RCPU: 55.2%,18.8%, SD/RSD: 1.2%,-22.0%
> >
> > ______________ numtxqs=32, vhosts=5 ___________________
> > # BW% CPU% RCPU% SD% RSD%
> > ________________________________________________________
> > 1 7.62 -38.03 -26.26 -50.00 -33.33
> > 2 28.95 20.46 21.62 0 -7.14
> > 4 84.05 60.79 45.74 -2.43 -12.42
> > 8 86.43 79.57 50.32 15.85 -3.10
> > 16 88.63 99.48 58.17 9.47 -13.10
> > 24 74.65 80.87 41.99 -1.81 -22.89
> > 32 63.86 59.21 23.58 -18.13 -36.37
> > 40 64.79 60.53 22.23 -15.77 -35.84
> > 48 49.68 26.93 .51 -36.40 -49.61
> > 64 54.69 36.50 5.41 -26.59 -43.23
> > 80 45.06 12.72 -13.25 -37.79 -52.08
> > 96 40.21 -3.16 -24.53 -39.92 -52.97
> > 128 36.33 -33.19 -43.66 -5.68 -20.49
> > ________________________________________________________
> > BW: 49.3%, CPU/RCPU: 15.5%,-8.2%, SD/RSD: -22.2%,-37.0%
> >
> >
> > Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
^ permalink raw reply
* Re: [PATCH 1/2 v3] xps: Improvements in TX queue selection
From: Tom Herbert @ 2010-10-25 17:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev, eric.dumazet
In-Reply-To: <20101024.153206.179940220.davem@davemloft.net>
On Sun, Oct 24, 2010 at 3:32 PM, David Miller <davem@davemloft.net> wrote:
> From: Tom Herbert <therbert@google.com>
> Date: Thu, 21 Oct 2010 13:17:08 -0700 (PDT)
>
>> @@ -822,8 +822,10 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
>> &md5);
>> tcp_header_size = tcp_options_size + sizeof(struct tcphdr);
>>
>> - if (tcp_packets_in_flight(tp) == 0)
>> + if (tcp_packets_in_flight(tp) == 0) {
>> tcp_ca_event(sk, CA_EVENT_TX_START);
>> + skb->ooo_okay = 1;
>> + }
>>
>
> You'll need to clear this flag the moment the first transmit of
> this packet happens, otherwise OOO won't be handled correctly in
> the event that fast retransmit is necessary later.
>
Would this be sufficient:
@@ -825,7 +825,8 @@ static int tcp_transmit_skb(struct sock *sk,
struct sk_buff *skb
if (tcp_packets_in_flight(tp) == 0) {
tcp_ca_event(sk, CA_EVENT_TX_START);
skb->ooo_okay = 1;
- }
+ } else
+ skb->ooo_okay = 0;
^ permalink raw reply
* qlge changes for net-next
From: Ron Mercer @ 2010-10-25 16:17 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, jitendra.kalsaria, ying.lok
Changes for next-next:
1) Restore VLAN settings after reset.
2) Add firmware info to ethtool reg dump.
3) Version change.
^ permalink raw reply
* [net-next PATCH 1/3] qlge: Restoring the vlan setting.
From: Ron Mercer @ 2010-10-25 16:17 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, jitendra.kalsaria, ying.lok
In-Reply-To: <1288023473-31490-1-git-send-email-ron.mercer@qlogic.com>
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge_main.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index ba0053d..ed0c63d 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -2382,6 +2382,20 @@ static void qlge_vlan_rx_kill_vid(struct net_device *ndev, u16 vid)
}
+static void qlge_restore_vlan(struct ql_adapter *qdev)
+{
+ qlge_vlan_rx_register(qdev->ndev, qdev->vlgrp);
+
+ if (qdev->vlgrp) {
+ u16 vid;
+ for (vid = 0; vid < VLAN_N_VID; vid++) {
+ if (!vlan_group_get_device(qdev->vlgrp, vid))
+ continue;
+ qlge_vlan_rx_add_vid(qdev->ndev, vid);
+ }
+ }
+}
+
/* MSI-X Multiple Vector Interrupt Handler for inbound completions. */
static irqreturn_t qlge_msix_rx_isr(int irq, void *dev_id)
{
@@ -3957,6 +3971,9 @@ static int ql_adapter_up(struct ql_adapter *qdev)
clear_bit(QL_PROMISCUOUS, &qdev->flags);
qlge_set_multicast_list(qdev->ndev);
+ /* Restore vlan setting. */
+ qlge_restore_vlan(qdev);
+
ql_enable_interrupts(qdev);
ql_enable_all_completion_interrupts(qdev);
netif_tx_start_all_queues(qdev->ndev);
--
1.6.0.2
^ permalink raw reply related
* [net-next PATCH 3/3] qlge: Version change to v1.00.00.27
From: Ron Mercer @ 2010-10-25 16:17 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, jitendra.kalsaria, ying.lok
In-Reply-To: <1288023473-31490-1-git-send-email-ron.mercer@qlogic.com>
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/qlge/qlge.h b/drivers/net/qlge/qlge.h
index 0474d20..69c4780 100644
--- a/drivers/net/qlge/qlge.h
+++ b/drivers/net/qlge/qlge.h
@@ -16,7 +16,7 @@
*/
#define DRV_NAME "qlge"
#define DRV_STRING "QLogic 10 Gigabit PCI-E Ethernet Driver "
-#define DRV_VERSION "v1.00.00.25.00.00-01"
+#define DRV_VERSION "v1.00.00.27.00.00-01"
#define WQ_ADDR_ALIGN 0x3 /* 4 byte alignment */
--
1.6.0.2
^ permalink raw reply related
* [net-next PATCH 2/3] qlge: Add firmware info to ethtool get regs.
From: Ron Mercer @ 2010-10-25 16:17 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, jitendra.kalsaria, ying.lok
In-Reply-To: <1288023473-31490-1-git-send-email-ron.mercer@qlogic.com>
By default we add firmware information to ethtool get regs.
Optionally firmware info can instead be sent to log.
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge.h | 2 ++
drivers/net/qlge/qlge_dbg.c | 21 ++++++++++++++++++++-
drivers/net/qlge/qlge_ethtool.c | 19 ++++++++++++++++---
3 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/drivers/net/qlge/qlge.h b/drivers/net/qlge/qlge.h
index a478786..0474d20 100644
--- a/drivers/net/qlge/qlge.h
+++ b/drivers/net/qlge/qlge.h
@@ -2221,6 +2221,7 @@ int ql_write_mpi_reg(struct ql_adapter *qdev, u32 reg, u32 data);
int ql_unpause_mpi_risc(struct ql_adapter *qdev);
int ql_pause_mpi_risc(struct ql_adapter *qdev);
int ql_hard_reset_mpi_risc(struct ql_adapter *qdev);
+int ql_soft_reset_mpi_risc(struct ql_adapter *qdev);
int ql_dump_risc_ram_area(struct ql_adapter *qdev, void *buf,
u32 ram_addr, int word_count);
int ql_core_dump(struct ql_adapter *qdev,
@@ -2237,6 +2238,7 @@ int ql_mb_set_mgmnt_traffic_ctl(struct ql_adapter *qdev, u32 control);
int ql_mb_get_port_cfg(struct ql_adapter *qdev);
int ql_mb_set_port_cfg(struct ql_adapter *qdev);
int ql_wait_fifo_empty(struct ql_adapter *qdev);
+void ql_get_dump(struct ql_adapter *qdev, void *buff);
void ql_gen_reg_dump(struct ql_adapter *qdev,
struct ql_reg_dump *mpi_coredump);
netdev_tx_t ql_lb_send(struct sk_buff *skb, struct net_device *ndev);
diff --git a/drivers/net/qlge/qlge_dbg.c b/drivers/net/qlge/qlge_dbg.c
index 4747492..fca804f 100644
--- a/drivers/net/qlge/qlge_dbg.c
+++ b/drivers/net/qlge/qlge_dbg.c
@@ -1317,9 +1317,28 @@ void ql_gen_reg_dump(struct ql_adapter *qdev,
status = ql_get_ets_regs(qdev, &mpi_coredump->ets[0]);
if (status)
return;
+}
+
+void ql_get_dump(struct ql_adapter *qdev, void *buff)
+{
+ /*
+ * If the dump has already been taken and is stored
+ * in our internal buffer and if force dump is set then
+ * just start the spool to dump it to the log file
+ * and also, take a snapshot of the general regs to
+ * to the user's buffer or else take complete dump
+ * to the user's buffer if force is not set.
+ */
- if (test_bit(QL_FRC_COREDUMP, &qdev->flags))
+ if (!test_bit(QL_FRC_COREDUMP, &qdev->flags)) {
+ if (!ql_core_dump(qdev, buff))
+ ql_soft_reset_mpi_risc(qdev);
+ else
+ netif_err(qdev, drv, qdev->ndev, "coredump failed!\n");
+ } else {
+ ql_gen_reg_dump(qdev, buff);
ql_get_core_dump(qdev);
+ }
}
/* Coredump to messages log file using separate worker thread */
diff --git a/drivers/net/qlge/qlge_ethtool.c b/drivers/net/qlge/qlge_ethtool.c
index 4892d64..8149cc9 100644
--- a/drivers/net/qlge/qlge_ethtool.c
+++ b/drivers/net/qlge/qlge_ethtool.c
@@ -375,7 +375,10 @@ static void ql_get_drvinfo(struct net_device *ndev,
strncpy(drvinfo->bus_info, pci_name(qdev->pdev), 32);
drvinfo->n_stats = 0;
drvinfo->testinfo_len = 0;
- drvinfo->regdump_len = 0;
+ if (!test_bit(QL_FRC_COREDUMP, &qdev->flags))
+ drvinfo->regdump_len = sizeof(struct ql_mpi_coredump);
+ else
+ drvinfo->regdump_len = sizeof(struct ql_reg_dump);
drvinfo->eedump_len = 0;
}
@@ -547,7 +550,12 @@ static void ql_self_test(struct net_device *ndev,
static int ql_get_regs_len(struct net_device *ndev)
{
- return sizeof(struct ql_reg_dump);
+ struct ql_adapter *qdev = netdev_priv(ndev);
+
+ if (!test_bit(QL_FRC_COREDUMP, &qdev->flags))
+ return sizeof(struct ql_mpi_coredump);
+ else
+ return sizeof(struct ql_reg_dump);
}
static void ql_get_regs(struct net_device *ndev,
@@ -555,7 +563,12 @@ static void ql_get_regs(struct net_device *ndev,
{
struct ql_adapter *qdev = netdev_priv(ndev);
- ql_gen_reg_dump(qdev, p);
+ ql_get_dump(qdev, p);
+ qdev->core_is_dumped = 0;
+ if (!test_bit(QL_FRC_COREDUMP, &qdev->flags))
+ regs->len = sizeof(struct ql_mpi_coredump);
+ else
+ regs->len = sizeof(struct ql_reg_dump);
}
static int ql_get_coalesce(struct net_device *dev, struct ethtool_coalesce *c)
--
1.6.0.2
^ permalink raw reply related
* Re: linux-next: build failure after merge of the final tree (net-current tree related)
From: Stephen Hemminger @ 2010-10-25 17:36 UTC (permalink / raw)
To: David Miller; +Cc: sfr, netdev, linux-next, linux-kernel, jchapman
In-Reply-To: <20101024.222602.71095343.davem@davemloft.net>
On Sun, 24 Oct 2010 22:26:02 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 25 Oct 2010 14:19:56 +1100
>
> > I wish doing that caused a build failure on other architectures ...
>
> Me too :-/
>
> > Subject: [PATCH] l2tp: static functions should not be exported
>
> I'll add this thanks Stephen.
The section mismatch warning on x86 is not shown by default
because there are still so many problems.
--
^ permalink raw reply
* [PATCH net-2.6] cxgb3: fix device opening error path
From: Divy Le Ray @ 2010-10-25 17:35 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Only negative return from bind_qsets() should be considered an error and
propagated.
It fixes an issue reported by IBM on P Series platform.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
Tested-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
drivers/net/cxgb3/cxgb3_main.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index a04ce6a..4e3c123 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -1266,11 +1266,13 @@ static int cxgb_up(struct adapter *adap)
}
if (!(adap->flags & QUEUES_BOUND)) {
- err = bind_qsets(adap);
- if (err) {
- CH_ERR(adap, "failed to bind qsets, err %d\n", err);
+ int ret = bind_qsets(adap);
+
+ if (ret < 0) {
+ CH_ERR(adap, "failed to bind qsets, err %d\n", ret);
t3_intr_disable(adap);
free_irq_resources(adap);
+ err = ret;
goto out;
}
adap->flags |= QUEUES_BOUND;
^ permalink raw reply related
* Re: [PATCH v2 10/14] ixgbe: Update ixgbe to use new vlan accleration.
From: Peter P Waskiewicz Jr @ 2010-10-25 17:50 UTC (permalink / raw)
To: Michał Mirosław
Cc: Jesse Gross, David Miller, netdev@vger.kernel.org,
Tantilov, Emil S, Kirsher, Jeffrey T
In-Reply-To: <AANLkTindxJD1a5UPV+6vWbDEeMUTy1QgPs1X8pT-b69D@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2322 bytes --]
On Fri, 2010-10-22 at 06:24 -0700, Michał Mirosław wrote:
> 2010/10/21 Jesse Gross <jesse@nicira.com>:
> > Make the ixgbe driver use the new vlan accleration model.
> [...]
> > --- a/drivers/net/ixgbe/ixgbe_main.c
> > +++ b/drivers/net/ixgbe/ixgbe_main.c
> > @@ -954,17 +954,13 @@ static void ixgbe_receive_skb(struct ixgbe_q_vector *q_vector,
> > bool is_vlan = (status & IXGBE_RXD_STAT_VP);
> > u16 tag = le16_to_cpu(rx_desc->wb.upper.vlan);
> >
> > - if (!(adapter->flags & IXGBE_FLAG_IN_NETPOLL)) {
> > - if (adapter->vlgrp && is_vlan && (tag & VLAN_VID_MASK))
> > - vlan_gro_receive(napi, adapter->vlgrp, tag, skb);
> > - else
> > - napi_gro_receive(napi, skb);
> > - } else {
> > - if (adapter->vlgrp && is_vlan && (tag & VLAN_VID_MASK))
> > - vlan_hwaccel_rx(skb, adapter->vlgrp, tag);
> > - else
> > - netif_rx(skb);
> > - }
> > + if (is_vlan && (tag & VLAN_VID_MASK))
> > + __vlan_hwaccel_put_tag(skb, tag);
>
> I know that this is carried over from the driver, but why tag == 0 is
> treated differently here? VID0 is somewhat special, as normally it
> means 802.1p packet, but i.e. in embedded world people are using it as
> normal VID. It would be nice to have this handled consistently in the
> VLAN core - deliver to base dev (tag stripped) if vlan 0 is not
> configured and to vlan dev if it is.
ixgbe handles VLAN 0 differently because that's the tag that's used when
DCB is enabled, and no VLAN is configured. We have to insert the 802.1p
tag for DCB to work, but the OS won't know about the 802.1q tag, and
ends up dropping the frame. So we enable VLAN ID 0 in the HW and tell
it to strip the tag, so we can still pass the frame up the stack.
>
> > +
> > + if (!(adapter->flags & IXGBE_FLAG_IN_NETPOLL))
> > + napi_gro_receive(napi, skb);
> > + else
> > + netif_rx(skb);
> > }
> >
> > /**
>
> Best Regards,
> Michał Mirosław
--
-----------------------------------------------------------
Peter P Waskiewicz Jr LAN Access Division
peter.p.waskiewicz.jr@intel.com Intel Corp.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4394 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: rtl818x: request DMA-able memory
From: Serafeim Zanikolas @ 2010-10-25 17:44 UTC (permalink / raw)
To: John W. Linville
Cc: Hin-Tak Leung, Larry Finger, herton, joe, davem, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20101025142232.GC2414@tuxdriver.com>
On Mon, Oct 25, 2010 at 10:22:32AM -0400, John W. Linville wrote:
> On Mon, Oct 25, 2010 at 03:11:22PM +0100, Hin-Tak Leung wrote:
> >
> >
> > Larry Finger wrote:
> > >On 10/24/2010 03:32 PM, Serafeim Zanikolas wrote:
> > >>Despite the indicated intention in comment, the kmalloc() call was not
> > >>explicitly requesting memory from ZONE_DMA.
> > >>
> > >>Signed-off-by: Serafeim Zanikolas <sez@debian.org>
> > >>---
> > >> drivers/net/wireless/rtl818x/rtl8187_dev.c | 3 ++-
> > >> 1 files changed, 2 insertions(+), 1 deletions(-)
> > >>
> > >>diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
> > >>index 38fa824..771794d 100644
> > >>--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
> > >>+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
> > >>@@ -1343,7 +1343,8 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
> > >> priv->is_rtl8187b = (id->driver_info == DEVICE_RTL8187B);
> > >> /* allocate "DMA aware" buffer for register accesses */
> > >>- priv->io_dmabuf = kmalloc(sizeof(*priv->io_dmabuf), GFP_KERNEL);
> > >>+ priv->io_dmabuf = kmalloc(sizeof(*priv->io_dmabuf),
> > >>+ GFP_DMA | GFP_KERNEL);
> > >> if (!priv->io_dmabuf) {
> > >> err = -ENOMEM;
> > >> goto err_free_dev;
> > >
> > >ACK.
> > >
> > >Larry
> >
> > Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
> >
> > I had a quick look for similiar constructs and AFAIK only the
> > b43/b43legacy drivers uses DMA buffers. Seems to be a rare practice.
> > Is that something we should or should not do?
>
> It doesn't mean what you think it means. It is a relic of the past,
> used to indicate memory below 16MB so that ISA devices could do DMA.
Right. Sorry for the noise.
-S
^ permalink raw reply
* Reproducible VLAN/e1000e crash in 2.6.36 vanilla.
From: Ben Greear @ 2010-10-25 17:57 UTC (permalink / raw)
To: NetDev
To re-create, setup 2 802.1q vlans on different physical interfaces on the same system,
set up routing rules such that send-to-self works, and pass traffic (UDP/IPv4 in this case,
but doesn't seem to matter).
Stop traffic, then attempt to create additional 802.1q vlans on the same physical interfaces.
The crash only appears to happen after having sent traffic on the interface.
Likely it will also crash if one system is sending to another, but so far we've
just tested sending-to-self.
This appears very reproducible for us, and appears to be the same problem that
I had reported against our hacked kernel here:
http://www.spinics.net/lists/netdev/msg144748.html
[root@ct503-60 ~]# general protection fault: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/virtual/net/eth2.103/type
CPU 2
Modules linked in: 8021q garp bridge stp llc veth arc4 michael_mic macvlan pktgen fuse nfs lockd fscach]
Pid: 0, comm: kworker/0:1 Not tainted 2.6.36 #32 X8DTU/X8DTU
RIP: 0010:[<ffffffff813cada1>] [<ffffffff813cada1>] vlan_hwaccel_do_receive+0x64/0xca
RSP: 0018:ffff880001a43c10 EFLAGS: 00010287
RAX: 0000000000000002 RBX: ffff88031d1b0200 RCX: ffff88032d600000
RDX: ffff880001a43c00 RSI: ffff88031d1b0200 RDI: 0000000000000001
RBP: ffff880001a43c30 R08: 0000000000000067 R09: ffff8803217268c0
R10: ffff88031d1b0228 R11: 00000000000005f2 R12: ffff88032d600000
R13: ffff10032f040890 R14: 0000000000000000 R15: ffff880330b6ae00
FS: 0000000000000000(0000) GS:ffff880001a40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000001d07be8 CR3: 0000000001642000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kworker/0:1 (pid: 0, threadinfo ffff8803321f0000, task ffff88033209f700)
Stack:
ffff880001a43c30 ffff88031d1b0200 ffff88032d600908 ffff88031d1b0208
<0> ffff880001a43c90 ffffffff81344313 ffff88031d1b0200 ffff88032d600908
<0> ffff880001a43c70 ffffffff81061d07 000000004cc5bf73 ffff88031d1b0200
Call Trace:
<IRQ>
[<ffffffff81344313>] __netif_receive_skb+0x36/0x3b3
[<ffffffff81061d07>] ? ktime_get_real+0x11/0x3e
[<ffffffff813454a5>] netif_receive_skb+0x67/0x6e
[<ffffffff81345b8c>] napi_skb_finish+0x24/0x3b
[<ffffffff813cb07f>] vlan_gro_receive+0x7b/0x80
[<ffffffffa016d5b9>] e1000_receive_skb+0x51/0x6d [e1000e]
[<ffffffffa016eeb0>] e1000_clean_rx_irq+0x1ed/0x292 [e1000e]
[<ffffffffa016f287>] e1000_clean+0x75/0x221 [e1000e]
[<ffffffff81345690>] net_rx_action+0xad/0x19c
[<ffffffff81048926>] __do_softirq+0xa8/0x135
[<ffffffff8100a99c>] call_softirq+0x1c/0x30
[<ffffffff8100c085>] do_softirq+0x41/0x7e
[<ffffffff81048ab8>] irq_exit+0x36/0x85
[<ffffffff8100b7bf>] do_IRQ+0xad/0xc4
[<ffffffff813ed4d3>] ret_from_intr+0x0/0x11
<EOI>
[<ffffffff8120dab2>] ? intel_idle+0xe6/0x112
[<ffffffff8120da95>] ? intel_idle+0xc9/0x112
[<ffffffff8131d121>] cpuidle_idle_call+0xab/0xe6
[<ffffffff81008dd5>] cpu_idle+0x59/0xb5
[<ffffffff813e6da8>] start_secondary+0x1a9/0x1ae
Code: 0d 0f b7 c0 41 8b 44 85 04 66 c7 83 bc 00 00 00 00 00 89 43 78 4d 8b ad d8 00 00 00 e8 c1 95 e0 f
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] drivers: rtl818x: request DMA-able memory
From: Larry Finger @ 2010-10-25 18:01 UTC (permalink / raw)
To: htl10-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f
Cc: John W. Linville, Serafeim Zanikolas,
herton-4qZELD6Fgxg39yzSjRtAkw, joe-6d6DIl74uiNBDgjK7y7TUQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <902045.66378.qm-gyycVyw5OoDyX4RqAA4FmIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>
On 10/25/2010 10:39 AM, Hin-Tak Leung wrote:
>
> okay - sorry about the confusion - I was grep'ing for GFP_DMA and only b43/b43lagacy have it and it is relatively rare. AFAIK none of the rtl8187 devices are non-USB... probably a NACK then, but I should ask Serafeim if there is a reason for him to submit this patch? (other than "it says dma"...)
There are some devices driven by b43/b43legacy that implement only 24-bit DMA.
For that reason, they need to allocate DMA buffers in the low 16 MB of RAM. For
rtl8187, that consideration does not apply.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: b43legacy: fix compile error
From: Larry Finger @ 2010-10-25 18:11 UTC (permalink / raw)
To: Eric Dumazet
Cc: Arnd Hannemann, David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1288021905.2826.142.camel@edumazet-laptop>
On 10/25/2010 10:51 AM, Eric Dumazet wrote:
> Le lundi 25 octobre 2010 à 10:32 -0500, Larry Finger a écrit :
>> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
>>> On todays linus tree the following compile error happened to me:
>>>
>>> CC [M] drivers/net/wireless/b43legacy/xmit.o
>>> In file included from include/net/dst.h:11,
>>> from drivers/net/wireless/b43legacy/xmit.c:31:
>>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
>>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
>>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
>>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_add':
>>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_init':
>>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_destroy':
>>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
>>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
>>> make[2]: *** [drivers/net/wireless] Error 2
>>> make[1]: *** [drivers/net] Error 2
>>> make: *** [drivers] Error 2
>>>
>>> This patch fixes this issue by adding "linux/cache.h" as an include to
>>> "include/net/dst_ops.h".
>>
>> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
>> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
>
> Well, x86_64 must include cache.h, this is probably why I missed it in
> my build tests.
>
> I wonder also why #include <net/dst.h> is needed at all in this
> driver...
>
> diff --git a/drivers/net/wireless/b43legacy/xmit.c
> b/drivers/net/wireless/b43legacy/xmit.c
> index 7d177d9..a261aec 100644
> --- a/drivers/net/wireless/b43legacy/xmit.c
> +++ b/drivers/net/wireless/b43legacy/xmit.c
> @@ -28,8 +28,6 @@
>
> */
>
> -#include <net/dst.h>
> -
> #include "xmit.h"
> #include "phy.h"
> #include "dma.h"
I have no idea why that header was included - likely historical in the
transformation from bcm43xx to b43legacy. For completeness, there are 2 more
places to change:
Index: linux-2.6/drivers/net/wireless/b43legacy/dma.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/dma.c
+++ linux-2.6/drivers/net/wireless/b43legacy/dma.c
@@ -38,7 +38,6 @@
#include <linux/delay.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
-#include <net/dst.h>
/* 32bit DMA ops. */
static
Index: linux-2.6/drivers/net/wireless/b43legacy/main.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/main.c
+++ linux-2.6/drivers/net/wireless/b43legacy/main.c
@@ -41,7 +41,6 @@
#include <linux/skbuff.h>
#include <linux/dma-mapping.h>
#include <linux/slab.h>
-#include <net/dst.h>
#include <asm/unaligned.h>
#include "b43legacy.h"
Index: linux-2.6/drivers/net/wireless/b43legacy/xmit.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/xmit.c
+++ linux-2.6/drivers/net/wireless/b43legacy/xmit.c
@@ -28,8 +28,6 @@
*/
-#include <net/dst.h>
^ permalink raw reply
* Re: TCP always advertises zero window.
From: Andi Kleen @ 2010-10-25 18:18 UTC (permalink / raw)
To: Li Yu; +Cc: netdev@vger.kernel.org
In-Reply-To: <4CBFE924.2060103@gmail.com>
Li Yu <raise.sail@gmail.com> writes:
>
> According to source code, only MTU probing success and receive some non-zero length of L7 payload could grow tcp_sock->rcv_ssthresh. Because of we turn off MTU probing and TCP only received some zero-window probe from another end, so it seem that we have not any chance to update tcp_sock->rcv_ssthresh at all, so a dead loop come here.
The question is why are you turning off MTU probing?
-Andi
^ permalink raw reply
* Re: [PATCH] net: b43legacy: fix compile error
From: Arnd Hannemann @ 2010-10-25 18:26 UTC (permalink / raw)
To: Larry Finger; +Cc: David S. Miller, netdev, linux-kernel, linux-wireless
In-Reply-To: <4CC5A301.1080606@lwfinger.net>
Am 25.10.2010 17:32, schrieb Larry Finger:
> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
>> On todays linus tree the following compile error happened to me:
>>
>> CC [M] drivers/net/wireless/b43legacy/xmit.o
>> In file included from include/net/dst.h:11,
>> from drivers/net/wireless/b43legacy/xmit.c:31:
>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>> include/net/dst_ops.h: In function 'dst_entries_add':
>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>> include/net/dst_ops.h: In function 'dst_entries_init':
>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>> include/net/dst_ops.h: In function 'dst_entries_destroy':
>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
>> make[2]: *** [drivers/net/wireless] Error 2
>> make[1]: *** [drivers/net] Error 2
>> make: *** [drivers] Error 2
>>
>> This patch fixes this issue by adding "linux/cache.h" as an include to
>> "include/net/dst_ops.h".
>
> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
Exactly the same git describe here.
Maybe your arch includes cache.h already, in my case its a compile for ARM (shmobile).
Regards
Arnd
^ permalink raw reply
* Re: [PATCH] net: b43legacy: fix compile error
From: Larry Finger @ 2010-10-25 18:36 UTC (permalink / raw)
To: Arnd Hannemann
Cc: David S. Miller, netdev, linux-kernel, linux-wireless,
Eric Dumazet
In-Reply-To: <4CC5CBC4.7060308@arndnet.de>
On 10/25/2010 01:26 PM, Arnd Hannemann wrote:
> Am 25.10.2010 17:32, schrieb Larry Finger:
>> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
>>> On todays linus tree the following compile error happened to me:
>>>
>>> CC [M] drivers/net/wireless/b43legacy/xmit.o
>>> In file included from include/net/dst.h:11,
>>> from drivers/net/wireless/b43legacy/xmit.c:31:
>>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
>>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
>>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
>>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_add':
>>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_init':
>>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> include/net/dst_ops.h: In function 'dst_entries_destroy':
>>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
>>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
>>> make[2]: *** [drivers/net/wireless] Error 2
>>> make[1]: *** [drivers/net] Error 2
>>> make: *** [drivers] Error 2
>>>
>>> This patch fixes this issue by adding "linux/cache.h" as an include to
>>> "include/net/dst_ops.h".
>>
>> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
>> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
>
> Exactly the same git describe here.
> Maybe your arch includes cache.h already, in my case its a compile for ARM (shmobile).
That probably makes the difference. Using Eric's fix that removes the #include
<linux/dst.h> should be better. Does it work for you?
There are probably a lot more of the system includes that may not be needed. If
I send you a patch removing them, could you test?
Larry
^ permalink raw reply
* Re: [PATCH] net: b43legacy: fix compile error
From: Arnd Hannemann @ 2010-10-25 18:44 UTC (permalink / raw)
To: Larry Finger
Cc: David S. Miller, netdev, linux-kernel, linux-wireless,
Eric Dumazet
In-Reply-To: <4CC5CE47.2020607@lwfinger.net>
Am 25.10.2010 20:36, schrieb Larry Finger:
> On 10/25/2010 01:26 PM, Arnd Hannemann wrote:
>> Am 25.10.2010 17:32, schrieb Larry Finger:
>>> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
>>>> On todays linus tree the following compile error happened to me:
>>>>
>>>> CC [M] drivers/net/wireless/b43legacy/xmit.o
>>>> In file included from include/net/dst.h:11,
>>>> from drivers/net/wireless/b43legacy/xmit.c:31:
>>>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
>>>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
>>>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
>>>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>> include/net/dst_ops.h: In function 'dst_entries_add':
>>>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>> include/net/dst_ops.h: In function 'dst_entries_init':
>>>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>> include/net/dst_ops.h: In function 'dst_entries_destroy':
>>>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
>>>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
>>>> make[2]: *** [drivers/net/wireless] Error 2
>>>> make[1]: *** [drivers/net] Error 2
>>>> make: *** [drivers] Error 2
>>>>
>>>> This patch fixes this issue by adding "linux/cache.h" as an include to
>>>> "include/net/dst_ops.h".
>>>
>>> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
>>> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
>>
>> Exactly the same git describe here.
>> Maybe your arch includes cache.h already, in my case its a compile for ARM (shmobile).
>
> That probably makes the difference. Using Eric's fix that removes the #include
> <linux/dst.h> should be better. Does it work for you?
>
> There are probably a lot more of the system includes that may not be needed. If
> I send you a patch removing them, could you test?
As it turns out my card is not supported by b43legacy, but compilation testing,
sure I can test that.
Regards,
Arnd
^ permalink raw reply
* Re: [PATCH 1/2 v3] xps: Improvements in TX queue selection
From: David Miller @ 2010-10-25 18:56 UTC (permalink / raw)
To: therbert; +Cc: netdev, eric.dumazet
In-Reply-To: <AANLkTi=Pzxnf=bJXANwz8Rmd8GOUu9oxpO_YF6udJE01@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 25 Oct 2010 10:02:05 -0700
> Would this be sufficient:
>
> @@ -825,7 +825,8 @@ static int tcp_transmit_skb(struct sock *sk,
> struct sk_buff *skb
> if (tcp_packets_in_flight(tp) == 0) {
> tcp_ca_event(sk, CA_EVENT_TX_START);
> skb->ooo_okay = 1;
> - }
> + } else
> + skb->ooo_okay = 0;
Or, alternatively, you could clear it at the point it's tested in
the device transmit path.
This might make the changes for SCTP and other protocols much
easier.
For now, either way is fine with me.
^ permalink raw reply
* Re: [PATCH] net: b43legacy: fix compile error
From: Larry Finger @ 2010-10-25 18:59 UTC (permalink / raw)
To: Arnd Hannemann
Cc: David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Eric Dumazet
In-Reply-To: <4CC5D01C.20804-BCMAnToX5e2ELgA04lAiVw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]
On 10/25/2010 01:44 PM, Arnd Hannemann wrote:
> Am 25.10.2010 20:36, schrieb Larry Finger:
>> On 10/25/2010 01:26 PM, Arnd Hannemann wrote:
>>> Am 25.10.2010 17:32, schrieb Larry Finger:
>>>> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
>>>>> On todays linus tree the following compile error happened to me:
>>>>>
>>>>> CC [M] drivers/net/wireless/b43legacy/xmit.o
>>>>> In file included from include/net/dst.h:11,
>>>>> from drivers/net/wireless/b43legacy/xmit.c:31:
>>>>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
>>>>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
>>>>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
>>>>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>> include/net/dst_ops.h: In function 'dst_entries_add':
>>>>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>> include/net/dst_ops.h: In function 'dst_entries_init':
>>>>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>> include/net/dst_ops.h: In function 'dst_entries_destroy':
>>>>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
>>>>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
>>>>> make[2]: *** [drivers/net/wireless] Error 2
>>>>> make[1]: *** [drivers/net] Error 2
>>>>> make: *** [drivers] Error 2
>>>>>
>>>>> This patch fixes this issue by adding "linux/cache.h" as an include to
>>>>> "include/net/dst_ops.h".
>>>>
>>>> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
>>>> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
>>>
>>> Exactly the same git describe here.
>>> Maybe your arch includes cache.h already, in my case its a compile for ARM (shmobile).
>>
>> That probably makes the difference. Using Eric's fix that removes the #include
>> <linux/dst.h> should be better. Does it work for you?
>>
>> There are probably a lot more of the system includes that may not be needed. If
>> I send you a patch removing them, could you test?
>
> As it turns out my card is not supported by b43legacy, but compilation testing,
> sure I can test that.
If it is a Broadcom card, it is likely handled by b43.
Attached is a trial removal of a number of include statements. Does it compile?
Larry
[-- Attachment #2: b43legacy_remove_dst_h --]
[-- Type: text/plain, Size: 3134 bytes --]
Index: linux-2.6/drivers/net/wireless/b43legacy/dma.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/dma.c
+++ linux-2.6/drivers/net/wireless/b43legacy/dma.c
@@ -33,13 +33,6 @@
#include "debugfs.h"
#include "xmit.h"
-#include <linux/dma-mapping.h>
-#include <linux/pci.h>
-#include <linux/delay.h>
-#include <linux/skbuff.h>
-#include <linux/slab.h>
-#include <net/dst.h>
-
/* 32bit DMA ops. */
static
struct b43legacy_dmadesc_generic *op32_idx2desc(
Index: linux-2.6/drivers/net/wireless/b43legacy/main.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/main.c
+++ linux-2.6/drivers/net/wireless/b43legacy/main.c
@@ -29,20 +29,8 @@
*
*/
-#include <linux/delay.h>
-#include <linux/init.h>
-#include <linux/moduleparam.h>
-#include <linux/if_arp.h>
#include <linux/etherdevice.h>
#include <linux/firmware.h>
-#include <linux/wireless.h>
-#include <linux/workqueue.h>
-#include <linux/sched.h>
-#include <linux/skbuff.h>
-#include <linux/dma-mapping.h>
-#include <linux/slab.h>
-#include <net/dst.h>
-#include <asm/unaligned.h>
#include "b43legacy.h"
#include "main.h"
Index: linux-2.6/drivers/net/wireless/b43legacy/xmit.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/xmit.c
+++ linux-2.6/drivers/net/wireless/b43legacy/xmit.c
@@ -28,8 +28,6 @@
*/
-#include <net/dst.h>
-
#include "xmit.h"
#include "phy.h"
#include "dma.h"
Index: linux-2.6/drivers/net/wireless/b43legacy/phy.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/phy.c
+++ linux-2.6/drivers/net/wireless/b43legacy/phy.c
@@ -29,12 +29,6 @@
*/
-#include <linux/delay.h>
-#include <linux/pci.h>
-#include <linux/sched.h>
-#include <linux/slab.h>
-#include <linux/types.h>
-
#include "b43legacy.h"
#include "phy.h"
#include "main.h"
Index: linux-2.6/drivers/net/wireless/b43legacy/pio.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/pio.c
+++ linux-2.6/drivers/net/wireless/b43legacy/pio.c
@@ -28,10 +28,6 @@
#include "main.h"
#include "xmit.h"
-#include <linux/delay.h>
-#include <linux/slab.h>
-
-
static void tx_start(struct b43legacy_pioqueue *queue)
{
b43legacy_pio_write(queue, B43legacy_PIO_TXCTL,
Index: linux-2.6/drivers/net/wireless/b43legacy/radio.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/radio.c
+++ linux-2.6/drivers/net/wireless/b43legacy/radio.c
@@ -29,8 +29,6 @@
*/
-#include <linux/delay.h>
-
#include "b43legacy.h"
#include "main.h"
#include "phy.h"
Index: linux-2.6/drivers/net/wireless/b43legacy/sysfs.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43legacy/sysfs.c
+++ linux-2.6/drivers/net/wireless/b43legacy/sysfs.c
@@ -29,8 +29,6 @@
#include "phy.h"
#include "radio.h"
-#include <linux/capability.h>
^ permalink raw reply
* [PATCH] Enhance AF_PACKET implementation to not require high order contiguous memory allocation
From: nhorman @ 2010-10-25 19:06 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet, jpirko, Neil Horman
From: Neil Horman <nhorman@tuxdriver.com>
It was shown to me recently that systems under high load were driven very deep
into swap when tcpdump was run. The reason this happened was because the
AF_PACKET protocol has a SET_RINGBUFFER socket option that allows the user space
application to specify how many entries an AF_PACKET socket will have and how
large each entry will be. It seems the default setting for tcpdump is to set
the ring buffer to 32 entries of 64 Kb each, which implies 32 order 5
allocation. Thats difficult under good circumstances, and horrid under memory
pressure.
I thought it would be good to make that a bit more usable. I was going to do a
simple conversion of the ring buffer from contigous pages to iovecs, but
unfortunately, the metadata which AF_PACKET places in these buffers can easily
span a page boundary, and given that these buffers get mapped into user space,
and the data layout doesn't easily allow for a change to padding between frames
to avoid that, a simple iovec change is just going to break user space ABI
consistency.
So instead I've done this. This patch does the aforementioned change,
allocating an array of pages instead of one contiguous chunk, and then vmaps the
array into a contiguous memory space, so that it can still be accessed in the
same way it was before. This allows for a consisten user and kernel space
behavior for memory mapped AF_PACKET sockets, which at the same time relieving
the memory pressure placed on a system when tcpdump defaults are used.
Tested successfully by me.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
---
net/packet/af_packet.c | 94 +++++++++++++++++++++++++++++++++++++----------
1 files changed, 74 insertions(+), 20 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 3616f27..fad3891 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -163,8 +163,14 @@ struct packet_mreq_max {
static int packet_set_ring(struct sock *sk, struct tpacket_req *req,
int closing, int tx_ring);
+struct pkt_page_list {
+ unsigned int num_pages;
+ char *vmap_area;
+ unsigned long pages[0];
+};
+
struct packet_ring_buffer {
- char **pg_vec;
+ struct pkt_page_list **pg_vec;
unsigned int head;
unsigned int frames_per_block;
unsigned int frame_size;
@@ -283,7 +289,8 @@ static void *packet_lookup_frame(struct packet_sock *po,
pg_vec_pos = position / rb->frames_per_block;
frame_offset = position % rb->frames_per_block;
- h.raw = rb->pg_vec[pg_vec_pos] + (frame_offset * rb->frame_size);
+ h.raw = rb->pg_vec[pg_vec_pos]->vmap_area +
+ (frame_offset * rb->frame_size);
if (status != __packet_get_status(po, h.raw))
return NULL;
@@ -2322,41 +2329,86 @@ static const struct vm_operations_struct packet_mmap_ops = {
.close = packet_mm_close,
};
-static void free_pg_vec(char **pg_vec, unsigned int order, unsigned int len)
+static void free_one_pkt_list(struct pkt_page_list *pglist)
+{
+ int i;
+
+ if ((pglist->num_pages > 1) && (pglist->vmap_area))
+ vunmap(pglist->vmap_area);
+ for (i = 0; i < pglist->num_pages; i++)
+ free_pages(pglist->pages[i], 0);
+}
+
+static void free_pg_vec(struct pkt_page_list **pg_vec, unsigned int order,
+ unsigned int len)
{
int i;
- for (i = 0; i < len; i++) {
+ for (i = 0; i < len; i++)
if (likely(pg_vec[i]))
- free_pages((unsigned long) pg_vec[i], order);
- }
+ free_one_pkt_list(pg_vec[i]);
+
kfree(pg_vec);
}
-static inline char *alloc_one_pg_vec_page(unsigned long order)
+static inline struct pkt_page_list *alloc_one_pg_page_list(unsigned long order)
{
+ int i;
+ struct pkt_page_list *newlist;
gfp_t gfp_flags = GFP_KERNEL | __GFP_COMP | __GFP_ZERO | __GFP_NOWARN;
- return (char *) __get_free_pages(gfp_flags, order);
+
+ newlist = kzalloc(sizeof(struct pkt_page_list)+
+ (sizeof(void *)*(1<<order)), GFP_KERNEL);
+ if (!newlist)
+ return NULL;
+ newlist->num_pages = (1<<order);
+
+ for (i = 0; i < newlist->num_pages; i++) {
+ newlist->pages[i] = __get_free_pages(gfp_flags, 0);
+ if (!newlist->pages[i])
+ goto out_free;
+ }
+
+ return newlist;
+out_free:
+ free_one_pkt_list(newlist);
+ kfree(newlist);
+ return NULL;
}
-static char **alloc_pg_vec(struct tpacket_req *req, int order)
+static struct pkt_page_list **alloc_pg_vec(struct tpacket_req *req, int order)
{
unsigned int block_nr = req->tp_block_nr;
- char **pg_vec;
- int i;
+ struct pkt_page_list **pg_vec;
+ struct page **pages;
+ int i, j;
- pg_vec = kzalloc(block_nr * sizeof(char *), GFP_KERNEL);
- if (unlikely(!pg_vec))
+ pg_vec = kzalloc(block_nr * sizeof(struct pkt_page_list *), GFP_KERNEL);
+ pages = kzalloc(block_nr * sizeof(struct page *), GFP_KERNEL);
+
+ if (unlikely(!pg_vec || !pages))
goto out;
for (i = 0; i < block_nr; i++) {
- pg_vec[i] = alloc_one_pg_vec_page(order);
- if (unlikely(!pg_vec[i]))
- goto out_free_pgvec;
+ pg_vec[i] = alloc_one_pg_page_list(order);
+
+ if (order > 0) {
+ for (j = 0; j < pg_vec[i]->num_pages; j++)
+ pages[j] = virt_to_page(pg_vec[i]->pages[j]);
+
+ if (unlikely(!pg_vec[i]))
+ goto out_free_pgvec;
+ pg_vec[i]->vmap_area = vmap(pages, pg_vec[i]->num_pages,
+ VM_MAP, PAGE_KERNEL);
+ if (!pg_vec[i]->vmap_area)
+ goto out_free_pgvec;
+ } else
+ pg_vec[i]->vmap_area = (void *)pg_vec[i]->pages[0];
}
out:
+ kfree(pages);
return pg_vec;
out_free_pgvec:
@@ -2368,7 +2420,7 @@ out_free_pgvec:
static int packet_set_ring(struct sock *sk, struct tpacket_req *req,
int closing, int tx_ring)
{
- char **pg_vec = NULL;
+ struct pkt_page_list **pg_vec = NULL;
struct packet_sock *po = pkt_sk(sk);
int was_running, order = 0;
struct packet_ring_buffer *rb;
@@ -2530,11 +2582,13 @@ static int packet_mmap(struct file *file, struct socket *sock,
continue;
for (i = 0; i < rb->pg_vec_len; i++) {
- struct page *page = virt_to_page(rb->pg_vec[i]);
+ struct pkt_page_list *plist = rb->pg_vec[i];
int pg_num;
+ struct page *page;
- for (pg_num = 0; pg_num < rb->pg_vec_pages;
- pg_num++, page++) {
+ for (pg_num = 0; pg_num < plist->num_pages;
+ pg_num++) {
+ page = virt_to_page(plist->pages[pg_num]);
err = vm_insert_page(vma, start, page);
if (unlikely(err))
goto out;
--
1.7.2.3
^ permalink raw reply related
* Re: [net-next PATCH 1/3] qlge: Restoring the vlan setting.
From: David Miller @ 2010-10-25 19:07 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev, jitendra.kalsaria, ying.lok
In-Reply-To: <1288023473-31490-2-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Mon, 25 Oct 2010 09:17:51 -0700
> + if (qdev->vlgrp) {
> + u16 vid;
> + for (vid = 0; vid < VLAN_N_VID; vid++) {
> + if (!vlan_group_get_device(qdev->vlgrp, vid))
> + continue;
> + qlge_vlan_rx_add_vid(qdev->ndev, vid);
> + }
> + }
> +}
Please fix the indentation in this code block.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] be2net: Adding an option to use INTx instead of MSI-X
From: David Miller @ 2010-10-25 19:09 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev
In-Reply-To: <20101025111235.GA2024@emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Mon, 25 Oct 2010 16:42:35 +0530
> By default, be2net uses MSIx wherever possible.
> Adding a module parameter to use INTx for users who do not want to use MSIx.
>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Either add a new ethtool flag, or use the PCI subsystem facilities
for tweaking things to implement this.
Do not use a module option, otherwise every other networking driver
author will get the same "cool" idea, give the module option
different names, and the resulting user experience is terrible.
^ permalink raw reply
* Quota de courriel
From: System Administrator @ 2010-10-25 18:59 UTC (permalink / raw)
Sie haben die Lagerung für Ihr Postfach überschritten wird.
Sie werden nicht in der Lage zu senden oder zu empfangen, bis Sie neue
E-Mail Ihre E-Mail Quote zu aktualisieren.
Kopieren Sie den untenstehenden Link und füllen Sie das Formular, um Ihr
Konto zu aktualisieren.
http://www.do.my/e-mailaccountactivation/
System-Administrator
192.168.0.1
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build warnings
From: David Miller @ 2010-10-25 19:14 UTC (permalink / raw)
To: tomoya-linux-ECg8zkTtlr0C6LszWs/t0g
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
masa-korg-ECg8zkTtlr0C6LszWs/t0g, sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, wg-5Yr1BZd7O62+XT7JhA+gdA,
morinaga526-ECg8zkTtlr0C6LszWs/t0g,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CC4EC38.2040208-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
From: Tomoya <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Date: Mon, 25 Oct 2010 11:32:24 +0900
> @@ -255,21 +255,21 @@ static void pch_can_set_optmode(struct
> pch_can_priv *priv)
This patch has been corrupted by your email client.
^ 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