* 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
* Re: [PATCH 1/2] be2net: Call netif_carier_off() after register_netdev()
From: David Miller @ 2010-10-25 19:15 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev
In-Reply-To: <20101025111110.GA1990@emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Mon, 25 Oct 2010 16:41:10 +0530
> Calling netif_carrier_off before register_netdev was causing the network interface
> to miss a linkwatch pending event leading to an inconsistent state if the link
> is not up when interface is initialized.This is now invoked after register_netdev.
>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] be2net: Fix CSO for UDP packets
From: David Miller @ 2010-10-25 19:15 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev
In-Reply-To: <20101025111158.GA2009@emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Mon, 25 Oct 2010 16:41:58 +0530
> We're setting skb->ip_summed to CHECKSUM_NONE for all non-TCP pkts, making the stack
> recompute checksum.This is a bug for UDP pkts for which cso must be used.
>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6] cxgb3: fix device opening error path
From: David Miller @ 2010-10-25 19:15 UTC (permalink / raw)
To: divy; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20101025173502.27055.847.stgit@speedy5.asicdesigners.com>
From: Divy Le Ray <divy@chelsio.com>
Date: Mon, 25 Oct 2010 10:35:02 -0700
> 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>
Applied.
^ permalink raw reply
* Re: [PATCH] macb: Don't re-enable interrupts while in polling mode
From: David Miller @ 2010-10-25 19:15 UTC (permalink / raw)
To: Joshua.Hoke
Cc: nicolas.ferre, jpirko, peter.korsgaard, eric.dumazet,
haavard.skinnemoen, netdev, linux-kernel, akpm
In-Reply-To: <C8F551D39A7C724E987CF8DD11D3178304D7CC86@svr3.sixnetio.com>
From: "Joshua Hoke" <Joshua.Hoke@sixnet.com>
Date: Mon, 25 Oct 2010 07:44:22 -0400
> [PATCH] macb: Don't re-enable interrupts while in polling mode
Applied.
^ permalink raw reply
* Re: [PATCH] mlx4_en: Fix out of bounds array access
From: David Miller @ 2010-10-25 19:16 UTC (permalink / raw)
To: eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb
Cc: yevgenyp-VPRAkNaXOzVS1MOuV/RT9w, rdreier-FYB4Gu1CFyUAvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101025125647.GA7710@mtldesk30>
From: Eli Cohen <eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
Date: Mon, 25 Oct 2010 14:56:47 +0200
> When searching for a free entry in either mlx4_register_vlan() or
> mlx4_register_mac(), and there is no free entry, the loop terminates without
> updating the local variable free thus causing out of array bounds access. Fix
> this by adding a proper check outside the loop.
>
> Signed-off-by: Eli Cohen <eli-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: [RFC] ixgbe: v3 normalize frag_list usage
From: David Miller @ 2010-10-25 19:47 UTC (permalink / raw)
To: alexander.h.duyck
Cc: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan, netdev
In-Reply-To: <80769D7B14936844A23C0C43D9FBCF0F25BC8DEC85@orsmsx501.amr.corp.intel.com>
From: "Duyck, Alexander H" <alexander.h.duyck@intel.com>
Date: Fri, 8 Oct 2010 16:57:40 -0700
> Below is the new and improved version of the RSC chaining approach. Basically
> I am holding off on merging the SKB into the frame until the SKB has data in
> order to make it take a more standard approach.
>
> Let me know if this will work with the new pointer structure.
This variant looks great, thanks Alexander!
^ permalink raw reply
* Re: Nested GRE locking bug
From: David Miller @ 2010-10-25 19:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: ben, netdev, beatrice.barbe, 599816
In-Reply-To: <1287478956.2676.13.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 19 Oct 2010 11:02:36 +0200
> Le mardi 19 octobre 2010 à 01:53 -0700, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Thu, 14 Oct 2010 06:11:59 +0200
>>
>> > net-next-2.6 contains a fix for this, adding the perc_cpu
>> > xmit_recursion limit. We might push it to net-2.6
>>
>> We need to think a bit more about this.
>>
>> We are essentially now saying that one can only configure
>> tunnels 3 levels deep, and no more.
>>
>> I can guarentee you someone out there uses at least 4,
>> perhaps more.
>>
>> And those people will be broken by the new limit.
>>
>> So putting this into net-2.6 with such a low limit will
>> be quite dangerous.
>
> Well limit is actually 4, but I get your point ;)
I'll commit the following to upstream, and submit a combined
patch to -stable.
--------------------
net: Increase xmit RECURSION_LIMIT to 10.
Three is definitely too low, and we know from reports that GRE tunnels
stacked as deeply as 37 levels cause stack overflows, so pick some
reasonable value between those two.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/core/dev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 78b5a89..2c7da3a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2213,7 +2213,7 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
}
static DEFINE_PER_CPU(int, xmit_recursion);
-#define RECURSION_LIMIT 3
+#define RECURSION_LIMIT 10
/**
* dev_queue_xmit - transmit a buffer
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH] net: b43legacy: fix compile error
From: Eric Dumazet @ 2010-10-25 19:56 UTC (permalink / raw)
To: Larry Finger
Cc: Arnd Hannemann, David S. Miller, netdev, linux-kernel,
linux-wireless
In-Reply-To: <4CC5C863.9070801@lwfinger.net>
Le lundi 25 octobre 2010 à 13:11 -0500, Larry Finger a écrit :
> 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:
Anyway, Arnd patch is fine by me, I didnt want to supply an alternate
patch.
I only was wondering why the include was in this driver...
^ permalink raw reply
* Re: [net-next PATCH 1/3] qlge: Restoring the vlan setting.
From: Ron Mercer @ 2010-10-25 19:46 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Jitendra Kalsaria, Ying Ping Lok
In-Reply-To: <20101025.120739.104054830.davem@davemloft.net>
>From 4981e8d94411b282040bcee89f08e16eef5c608c Mon Sep 17 00:00:00 2001
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Mon, 25 Oct 2010 12:38:33 -0700
Subject: [net-next PATCH 1/3] qlge: Restoring the vlan setting.
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..5077d38 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
* Re: __bad_udelay in network driver breaks build
From: David Miller @ 2010-10-25 20:05 UTC (permalink / raw)
To: andi; +Cc: netdev
In-Reply-To: <20101018115230.GA27565@basil.fritz.box>
From: Andi Kleen <andi@firstfloor.org>
Date: Mon, 18 Oct 2010 13:52:30 +0200
>
> Current Linus master x86-64 allyesconfig fails with
>
> drivers/built-in.o: In function `tms380tr_chipset_init':
> tms380tr.c:(.text+0x10f02de): undefined reference to `__bad_udelay'
> tms380tr.c:(.text+0x10f03ab): undefined reference to `__bad_udelay'
> tms380tr.c:(.text+0x10f0400): undefined reference to `__bad_udelay'
> tms380tr.c:(.text+0x10f07b2): undefined reference to `__bad_udelay'
> tms380tr.c:(.text+0x10f08ed): undefined reference to `__bad_udelay'
> make[2]: *** [.tmp_vmlinux1] Error 1
Let me know if this fixes things:
--------------------
tms380tr: Use mdelay() in tms380tr_wait().
This driver tries to do up to half-second udelay()
calls, which overflows on x86-64.
Reported-by: Andi Kleen <andi@firstfloor.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/tokenring/tms380tr.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tokenring/tms380tr.c b/drivers/net/tokenring/tms380tr.c
index 663b886..7930203 100644
--- a/drivers/net/tokenring/tms380tr.c
+++ b/drivers/net/tokenring/tms380tr.c
@@ -1220,7 +1220,7 @@ void tms380tr_wait(unsigned long time)
tmp = schedule_timeout_interruptible(tmp);
} while(time_after(tmp, jiffies));
#else
- udelay(time);
+ mdelay(time / 1000);
#endif
}
--
1.7.3.2
^ permalink raw reply related
* Congratulations!! DEAR Winner
From: Jill Nash @ 2010-10-25 20:00 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: PAYMENT_OF_PRIZE_AND_CLAIM.pdf --]
[-- Type: application/pdf, Size: 191206 bytes --]
^ permalink raw reply
* Re: Nested GRE locking bug
From: Eric Dumazet @ 2010-10-25 20:08 UTC (permalink / raw)
To: David Miller; +Cc: ben, netdev, beatrice.barbe, 599816
In-Reply-To: <20101025.125347.28807251.davem@davemloft.net>
Le lundi 25 octobre 2010 à 12:53 -0700, David Miller a écrit :
> I'll commit the following to upstream, and submit a combined
> patch to -stable.
>
> --------------------
> net: Increase xmit RECURSION_LIMIT to 10.
>
> Three is definitely too low, and we know from reports that GRE tunnels
> stacked as deeply as 37 levels cause stack overflows, so pick some
> reasonable value between those two.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> net/core/dev.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 78b5a89..2c7da3a 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2213,7 +2213,7 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
> }
>
> static DEFINE_PER_CPU(int, xmit_recursion);
> -#define RECURSION_LIMIT 3
> +#define RECURSION_LIMIT 10
>
> /**
> * dev_queue_xmit - transmit a buffer
Perfect, thanks !
^ 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