* Re: net: more accurate skb truesize - regression on Microblaze
From: Eric Dumazet @ 2012-04-10 11:32 UTC (permalink / raw)
To: monstr; +Cc: netdev, John Williams, David Miller
In-Reply-To: <4F83F166.4010208@monstr.eu>
On Tue, 2012-04-10 at 10:37 +0200, Michal Simek wrote:
> On 04/10/2012 10:32 AM, Eric Dumazet wrote:
> > On Tue, 2012-04-10 at 10:27 +0200, Eric Dumazet wrote:
> >
> >> BTW, some NIC drivers are known to provide fat skb in their rx path, and
> >> need to be fixed as well. (Some others just lie about skb->truesize to
> >> avoid the tcp slowdown, see my previous iwlwifi patch)
> >>
> >>
> >
> > What is the driver you currently use on your platform ?
>
> Using Xilinx ll_temac(in mainline) and axi_emac.
>
ll_temac allocates XTE_MAX_JUMBO_FRAME_SIZE frames, even for MTU=1500 ?
Trying to allocate smaller packets would definitely help your tcp
receiver performance and overall reliability (order-0 allocations
instead of order-2)
^ permalink raw reply
* Re: net: more accurate skb truesize - regression on Microblaze
From: Michal Simek @ 2012-04-10 11:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, John Williams, David Miller
In-Reply-To: <1334057529.3126.90.camel@edumazet-glaptop>
On 04/10/2012 01:32 PM, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 10:37 +0200, Michal Simek wrote:
>> On 04/10/2012 10:32 AM, Eric Dumazet wrote:
>>> On Tue, 2012-04-10 at 10:27 +0200, Eric Dumazet wrote:
>>>
>>>> BTW, some NIC drivers are known to provide fat skb in their rx path, and
>>>> need to be fixed as well. (Some others just lie about skb->truesize to
>>>> avoid the tcp slowdown, see my previous iwlwifi patch)
>>>>
>>>>
>>>
>>> What is the driver you currently use on your platform ?
>>
>> Using Xilinx ll_temac(in mainline) and axi_emac.
>>
>
> ll_temac allocates XTE_MAX_JUMBO_FRAME_SIZE frames, even for MTU=1500 ?
yes.
>
> Trying to allocate smaller packets would definitely help your tcp
> receiver performance and overall reliability (order-0 allocations
> instead of order-2)
There is long history for ll_temac and axi emac drivers. and if you compare
them they are very similar with similar bugs.
In our distribution we are using older ll_temac driver where this is fixed.
Performance is much higher if you allocate buffers for actual mtu.
Thanks,
Michal
P.S.: Our plan is to start to use mainline drivers and fixing them to get
the same performance as we have with old one. It is one my todo list.
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH 0/2] adding tracepoints to vhost
From: Stefan Hajnoczi @ 2012-04-10 11:40 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, mst, linux-kernel, kvm, virtualization
In-Reply-To: <20120410025327.49693.93562.stgit@amd-6168-8-1.englab.nay.redhat.com>
On Tue, Apr 10, 2012 at 3:58 AM, Jason Wang <jasowang@redhat.com> wrote:
> To help in vhost analyzing, the following series adding basic tracepoints to
> vhost. Operations of both virtqueues and vhost works were traced in current
> implementation, net code were untouched. A top-like satistics displaying script
> were introduced to help the troubleshooting.
>
> TODO:
> - net specific tracepoints?
>
> ---
>
> Jason Wang (2):
> vhost: basic tracepoints
> tools: virtio: add a top-like utility for displaying vhost satistics
>
>
> drivers/vhost/trace.h | 153 ++++++++++++++++++++
> drivers/vhost/vhost.c | 17 ++
> tools/virtio/vhost_stat | 360 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 528 insertions(+), 2 deletions(-)
> create mode 100644 drivers/vhost/trace.h
> create mode 100755 tools/virtio/vhost_stat
Perhaps this can replace the vhost log feature? I'm not sure if
tracepoints support the right data types but it seems like vhost
debugging could be done using tracing with less code.
Stefan
^ permalink raw reply
* Re: [PATCH] net: orphan queued skbs if device tx can stall
From: Eric Dumazet @ 2012-04-10 11:45 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, linux-kernel, David S. Miller, Jamal Hadi Salim,
Stephen Hemminger, Jason Wang, Neil Horman, Jiri Pirko,
Jeff Kirsher, Michał Mirosław, Ben Hutchings,
Herbert Xu
In-Reply-To: <20120410112459.GA28825@redhat.com>
On Tue, 2012-04-10 at 14:25 +0300, Michael S. Tsirkin wrote:
> On Tue, Apr 10, 2012 at 12:04:19PM +0200, Eric Dumazet wrote:
> > On Tue, 2012-04-10 at 12:31 +0300, Michael S. Tsirkin wrote:
> >
> > > True. Still this is the only interface we have for controlling
> > > the internal queue length so it seems safe to assume someone
> > > is using it for this purpose.
> > >
> >
> > So to workaround a problem in tun, you want to hack net/core/dev.c :(
>
> Sorry about being unclear, I'm just saying that your patch assumes
> tx_queue_len == 0 since you set it that way at device init but we can't
> rely on this as existing users might have changed that value.
> One way to fix would be a patch at the bottom: then we
> can leave tun to treat tx_queue_len like it always did.
> ----
>
> We don't want a queue for tun since it can stall forever, but userspace
> might tweak it's tx_queue_len as a way to control RX queue depth,
> and we don't want to break userspace. Use a private flag to disable queue.
>
> Warning: untested.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
> index 27883d1..644ca53 100644
> --- a/net/sched/sch_generic.c
> +++ b/net/sched/sch_generic.c
> @@ -695,7 +692,7 @@ static void attach_one_default_qdisc(struct net_device *dev,
> {
> struct Qdisc *qdisc = &noqueue_qdisc;
>
> - if (dev->tx_queue_len) {
> + if (dev->tx_queue_len && !(dev->priv_flags & IFF_TX_CAN_STALL)) {
> qdisc = qdisc_create_dflt(dev_queue,
> &pfifo_fast_ops, TC_H_ROOT);
> if (!qdisc) {
Thing is this function is called before userspace can tweak tx_queue_len
So if you create a vlan device (this sets tx_queue_len to 0), no qdisc
is attached.
If later userspace changes tx_queue_len to this device, qdisc wont
automatically be created/attached.
Really, tx_queue_len is private to net/sched layer, it should not be
used by tun device to control a receive queue limit.
Please try to not hack net/sched or net/core for your needs.
Its not because tun abused tx_queue_len in the past we must keep this
hack forever.
In ethernet drivers, TX ring size is controlled by ethtool -g
Why tun driver would use another way ?
^ permalink raw reply
* Re: net: more accurate skb truesize - regression on Microblaze
From: Eric Dumazet @ 2012-04-10 11:50 UTC (permalink / raw)
To: monstr; +Cc: netdev, John Williams, David Miller
In-Reply-To: <4F841BB9.2030209@monstr.eu>
On Tue, 2012-04-10 at 13:38 +0200, Michal Simek wrote:
> On 04/10/2012 01:32 PM, Eric Dumazet wrote:
> >
> > ll_temac allocates XTE_MAX_JUMBO_FRAME_SIZE frames, even for MTU=1500 ?
>
> yes.
>
> >
> > Trying to allocate smaller packets would definitely help your tcp
> > receiver performance and overall reliability (order-0 allocations
> > instead of order-2)
>
> There is long history for ll_temac and axi emac drivers. and if you compare
> them they are very similar with similar bugs.
> In our distribution we are using older ll_temac driver where this is fixed.
> Performance is much higher if you allocate buffers for actual mtu.
>
> Thanks,
> Michal
>
> P.S.: Our plan is to start to use mainline drivers and fixing them to get
> the same performance as we have with old one. It is one my todo list.
Ah good, because this 9000+pad versus 1500+pad allocation is way more
problematic than the (small) change on skb->truesize you bisected ;)
^ permalink raw reply
* Re: net: more accurate skb truesize - regression on Microblaze
From: Michal Simek @ 2012-04-10 12:12 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, John Williams, David Miller
In-Reply-To: <1334058625.3126.101.camel@edumazet-glaptop>
On 04/10/2012 01:50 PM, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 13:38 +0200, Michal Simek wrote:
>> On 04/10/2012 01:32 PM, Eric Dumazet wrote:
>>>
>>> ll_temac allocates XTE_MAX_JUMBO_FRAME_SIZE frames, even for MTU=1500 ?
>>
>> yes.
>>
>>>
>>> Trying to allocate smaller packets would definitely help your tcp
>>> receiver performance and overall reliability (order-0 allocations
>>> instead of order-2)
>>
>> There is long history for ll_temac and axi emac drivers. and if you compare
>> them they are very similar with similar bugs.
>> In our distribution we are using older ll_temac driver where this is fixed.
>> Performance is much higher if you allocate buffers for actual mtu.
>>
>> Thanks,
>> Michal
>>
>> P.S.: Our plan is to start to use mainline drivers and fixing them to get
>> the same performance as we have with old one. It is one my todo list.
>
> Ah good, because this 9000+pad versus 1500+pad allocation is way more
> problematic than the (small) change on skb->truesize you bisected ;)
yeah I know. Currently for me is the most important thing to have stable
driver which is ancient one and start to work on mainline to add there all features
and do more testing before we will add it to customers.
I have found it because I have compared the same driver with different kernel
versions and there was performance regression. Comparing with old one will show
different results. :-)
I will keep you in the loop when I start to fix mainline driver.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH] netfilter: don't scale the size of the window up twice
From: Pablo Neira Ayuso @ 2012-04-10 12:35 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Patrick McHardy, David S. Miller, netfilter-devel, netdev,
Changli Gao
In-Reply-To: <alpine.DEB.2.00.1204042100390.21828@blackhole.kfki.hu>
On Wed, Apr 04, 2012 at 09:05:26PM +0200, Jozsef Kadlecsik wrote:
> On Wed, 4 Apr 2012, Pablo Neira Ayuso wrote:
>
> > On Mon, Apr 02, 2012 at 11:25:06AM +0800, Changli Gao wrote:
> > > For a picked up connection, the window win is scaled twice: one is by the
> > > initialization code, and the other is by the sender updating code.
> > >
> > > I use the temporary variable swin instead of modifying the variable win.
> > >
> > > Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> > > ---
> > > net/netfilter/nf_conntrack_proto_tcp.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
> > > index 361eade..0d07a1d 100644
> > > --- a/net/netfilter/nf_conntrack_proto_tcp.c
> > > +++ b/net/netfilter/nf_conntrack_proto_tcp.c
> > > @@ -584,8 +584,8 @@ static bool tcp_in_window(const struct nf_conn *ct,
> > > * Let's try to use the data from the packet.
> > > */
> > > sender->td_end = end;
> > > - win <<= sender->td_scale;
> > > - sender->td_maxwin = (win == 0 ? 1 : win);
> > > + swin = win << sender->td_scale;
> > > + sender->td_maxwin = (swin == 0 ? 1 : swin);
> > > sender->td_maxend = end + sender->td_maxwin;
> > > /*
> > > * We haven't seen traffic in the other direction yet
> >
> > Jozsef, do you remember if this is intentional?
>
> No, it's a good spotting.
>
> Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] netfilter: fix incorrect logic in nf_conntrack_init_net
From: Pablo Neira Ayuso @ 2012-04-10 12:36 UTC (permalink / raw)
To: Gao feng; +Cc: netfilter-devel, netdev
In-Reply-To: <1333850908-3108-1-git-send-email-gaofeng@cn.fujitsu.com>
On Sun, Apr 08, 2012 at 10:08:28AM +0800, Gao feng wrote:
> in function nf_conntrack_init_net,when nf_conntrack_timeout_init falied,
> we should call nf_conntrack_ecache_fini to do rollback.
> but the current code calls nf_conntrack_timeout_fini.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: orphan queued skbs if device tx can stall
From: Michael S. Tsirkin @ 2012-04-10 12:41 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, linux-kernel, David S. Miller, Jamal Hadi Salim,
Stephen Hemminger, Jason Wang, Neil Horman, Jiri Pirko,
Jeff Kirsher, Michał Mirosław, Ben Hutchings,
Herbert Xu
In-Reply-To: <1334058300.3126.99.camel@edumazet-glaptop>
On Tue, Apr 10, 2012 at 01:45:00PM +0200, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 14:25 +0300, Michael S. Tsirkin wrote:
> > On Tue, Apr 10, 2012 at 12:04:19PM +0200, Eric Dumazet wrote:
> > > On Tue, 2012-04-10 at 12:31 +0300, Michael S. Tsirkin wrote:
> > >
> > > > True. Still this is the only interface we have for controlling
> > > > the internal queue length so it seems safe to assume someone
> > > > is using it for this purpose.
> > > >
> > >
> > > So to workaround a problem in tun, you want to hack net/core/dev.c :(
> >
> > Sorry about being unclear, I'm just saying that your patch assumes
> > tx_queue_len == 0 since you set it that way at device init but we can't
> > rely on this as existing users might have changed that value.
> > One way to fix would be a patch at the bottom: then we
> > can leave tun to treat tx_queue_len like it always did.
>
>
> > ----
> >
> > We don't want a queue for tun since it can stall forever, but userspace
> > might tweak it's tx_queue_len as a way to control RX queue depth,
> > and we don't want to break userspace. Use a private flag to disable queue.
> >
> > Warning: untested.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
> > index 27883d1..644ca53 100644
> > --- a/net/sched/sch_generic.c
> > +++ b/net/sched/sch_generic.c
> > @@ -695,7 +692,7 @@ static void attach_one_default_qdisc(struct net_device *dev,
> > {
> > struct Qdisc *qdisc = &noqueue_qdisc;
> >
> > - if (dev->tx_queue_len) {
> > + if (dev->tx_queue_len && !(dev->priv_flags & IFF_TX_CAN_STALL)) {
> > qdisc = qdisc_create_dflt(dev_queue,
> > &pfifo_fast_ops, TC_H_ROOT);
> > if (!qdisc) {
>
>
> Thing is this function is called before userspace can tweak tx_queue_len
>
> So if you create a vlan device (this sets tx_queue_len to 0), no qdisc
> is attached.
>
> If later userspace changes tx_queue_len to this device, qdisc wont
> automatically be created/attached.
True. But there's another place where this can happen - after
dev_change_net_namespace, no?
This calls dev_shutdown.
> Really, tx_queue_len is private to net/sched layer, it should not be
> used by tun device to control a receive queue limit.
>
> Please try to not hack net/sched or net/core for your needs.
>
> Its not because tun abused tx_queue_len in the past we must keep this
> hack forever.
>
> In ethernet drivers, TX ring size is controlled by ethtool -g
>
> Why tun driver would use another way ?
>
I think it's a bad interface too but it's in a userspace ABI
now so I suspect we are stuck with it for now. We can try deprecating
but we can't just drop it.
--
MST
^ permalink raw reply
* Re: [PATCH 0/2] adding tracepoints to vhost
From: Michael S. Tsirkin @ 2012-04-10 12:42 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <CAJSP0QWA1z6_YQe9hhpG7bCyZQarmU5NXbHsLGTL_zPTk3dOUA@mail.gmail.com>
On Tue, Apr 10, 2012 at 12:40:50PM +0100, Stefan Hajnoczi wrote:
> On Tue, Apr 10, 2012 at 3:58 AM, Jason Wang <jasowang@redhat.com> wrote:
> > To help in vhost analyzing, the following series adding basic tracepoints to
> > vhost. Operations of both virtqueues and vhost works were traced in current
> > implementation, net code were untouched. A top-like satistics displaying script
> > were introduced to help the troubleshooting.
> >
> > TODO:
> > - net specific tracepoints?
> >
> > ---
> >
> > Jason Wang (2):
> > vhost: basic tracepoints
> > tools: virtio: add a top-like utility for displaying vhost satistics
> >
> >
> > drivers/vhost/trace.h | 153 ++++++++++++++++++++
> > drivers/vhost/vhost.c | 17 ++
> > tools/virtio/vhost_stat | 360 +++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 528 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/vhost/trace.h
> > create mode 100755 tools/virtio/vhost_stat
>
> Perhaps this can replace the vhost log feature? I'm not sure if
> tracepoints support the right data types but it seems like vhost
> debugging could be done using tracing with less code.
>
> Stefan
vhost log is not a debugging tool, it logs memory accesses for
migration.
^ permalink raw reply
* [PATCH 0/5] netfilter fixes for 3.4-rc2
From: pablo @ 2012-04-10 12:48 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
From: Pablo Neira Ayuso <pablo@netfilter.org>
Hi David,
The following patchset includes netfilter fixes for 3.4-rc2, they are:
* A couple of fixes for the IPv4 connection tracker from Jozsef. One
to behave consistently with IPv6 and to follow the conntrack policy
(ie. don't drop, the user controls what to do by dropping invalid
packet via iptables). The other one checks for invalid IPv4 ihl
values that go further the packet boundary.
* Fix missing ip6t_ext_hdr symbol if ip6tables is compiled xt_LOG
is compiled built-in and ip6tables as module by myself.
* One fix for the error path of nf_conntrack_init_net introduced by
the recently added nf_conntrack_timeout infrastructure from Gao Feng.
* We don't want to scale the window twice for picked up connection in
the nf_ct_tcp code, from Changli Gao.
You can pull changes these from:
git://1984.lsi.us.es/net master
Changli Gao (1):
netfilter: nf_ct_tcp: don't scale the size of the window up twice
Gao feng (1):
netfilter: nf_conntrack: fix incorrect logic in nf_conntrack_init_net
Jozsef Kadlecsik (2):
netfilter: nf_ct_ipv4: handle invalid IPv4 and IPv6 packets consistently
netfilter: nf_ct_ipv4: packets with wrong ihl are invalid
Pablo Neira Ayuso (1):
netfilter: ip6_tables: ip6t_ext_hdr is now static inline
include/linux/netfilter_ipv6/ip6_tables.h | 12 +++++++++++-
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 12 ++++++++++--
net/ipv6/netfilter/ip6_tables.c | 14 --------------
net/netfilter/nf_conntrack_core.c | 2 +-
net/netfilter/nf_conntrack_proto_tcp.c | 4 ++--
5 files changed, 24 insertions(+), 20 deletions(-)
--
1.7.2.5
^ permalink raw reply
* [PATCH 1/5] netfilter: nf_ct_tcp: don't scale the size of the window up twice
From: pablo @ 2012-04-10 12:48 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1334062141-3962-1-git-send-email-pablo@netfilter.org>
From: Changli Gao <xiaosuo@gmail.com>
For a picked up connection, the window win is scaled twice: one is by the
initialization code, and the other is by the sender updating code.
I use the temporary variable swin instead of modifying the variable win.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_conntrack_proto_tcp.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index 361eade..0d07a1d 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -584,8 +584,8 @@ static bool tcp_in_window(const struct nf_conn *ct,
* Let's try to use the data from the packet.
*/
sender->td_end = end;
- win <<= sender->td_scale;
- sender->td_maxwin = (win == 0 ? 1 : win);
+ swin = win << sender->td_scale;
+ sender->td_maxwin = (swin == 0 ? 1 : swin);
sender->td_maxend = end + sender->td_maxwin;
/*
* We haven't seen traffic in the other direction yet
--
1.7.2.5
^ permalink raw reply related
* [PATCH 3/5] netfilter: nf_ct_ipv4: handle invalid IPv4 and IPv6 packets consistently
From: pablo @ 2012-04-10 12:48 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1334062141-3962-1-git-send-email-pablo@netfilter.org>
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
IPv6 conntrack marked invalid packets as INVALID and let the user
drop those by an explicit rule, while IPv4 conntrack dropped such
packets itself.
IPv4 conntrack is changed so that it marks INVALID packets and let
the user to drop them.
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
index de9da21..750b06a 100644
--- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
@@ -74,12 +74,12 @@ static int ipv4_get_l4proto(const struct sk_buff *skb, unsigned int nhoff,
iph = skb_header_pointer(skb, nhoff, sizeof(_iph), &_iph);
if (iph == NULL)
- return -NF_DROP;
+ return -NF_ACCEPT;
/* Conntrack defragments packets, we might still see fragments
* inside ICMP packets though. */
if (iph->frag_off & htons(IP_OFFSET))
- return -NF_DROP;
+ return -NF_ACCEPT;
*dataoff = nhoff + (iph->ihl << 2);
*protonum = iph->protocol;
--
1.7.2.5
^ permalink raw reply related
* [PATCH 4/5] netfilter: nf_ct_ipv4: packets with wrong ihl are invalid
From: pablo @ 2012-04-10 12:49 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1334062141-3962-1-git-send-email-pablo@netfilter.org>
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
It was reported that the Linux kernel sometimes logs:
klogd: [2629147.402413] kernel BUG at net / netfilter /
nf_conntrack_proto_tcp.c: 447!
klogd: [1072212.887368] kernel BUG at net / netfilter /
nf_conntrack_proto_tcp.c: 392
ipv4_get_l4proto() in nf_conntrack_l3proto_ipv4.c and tcp_error() in
nf_conntrack_proto_tcp.c should catch malformed packets, so the errors
at the indicated lines - TCP options parsing - should not happen.
However, tcp_error() relies on the "dataoff" offset to the TCP header,
calculated by ipv4_get_l4proto(). But ipv4_get_l4proto() does not check
bogus ihl values in IPv4 packets, which then can slip through tcp_error()
and get caught at the TCP options parsing routines.
The patch fixes ipv4_get_l4proto() by invalidating packets with bogus
ihl value.
The patch closes netfilter bugzilla id 771.
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
index 750b06a..cf73cc7 100644
--- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
@@ -84,6 +84,14 @@ static int ipv4_get_l4proto(const struct sk_buff *skb, unsigned int nhoff,
*dataoff = nhoff + (iph->ihl << 2);
*protonum = iph->protocol;
+ /* Check bogus IP headers */
+ if (*dataoff > skb->len) {
+ pr_debug("nf_conntrack_ipv4: bogus IPv4 packet: "
+ "nhoff %u, ihl %u, skblen %u\n",
+ nhoff, iph->ihl << 2, skb->len);
+ return -NF_ACCEPT;
+ }
+
return NF_ACCEPT;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH 2/5] netfilter: ip6_tables: ip6t_ext_hdr is now static inline
From: pablo @ 2012-04-10 12:48 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1334062141-3962-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
We may hit this in xt_LOG:
net/built-in.o:xt_LOG.c:function dump_ipv6_packet:
error: undefined reference to 'ip6t_ext_hdr'
happens with these config options:
CONFIG_NETFILTER_XT_TARGET_LOG=y
CONFIG_IP6_NF_IPTABLES=m
ip6t_ext_hdr is fairly small and it is called in the packet path.
Make it static inline.
Reported-by: Simon Kirby <sim@netnation.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/linux/netfilter_ipv6/ip6_tables.h | 12 +++++++++++-
net/ipv6/netfilter/ip6_tables.c | 14 --------------
2 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/include/linux/netfilter_ipv6/ip6_tables.h b/include/linux/netfilter_ipv6/ip6_tables.h
index f549adc..1bc898b 100644
--- a/include/linux/netfilter_ipv6/ip6_tables.h
+++ b/include/linux/netfilter_ipv6/ip6_tables.h
@@ -287,7 +287,17 @@ extern unsigned int ip6t_do_table(struct sk_buff *skb,
struct xt_table *table);
/* Check for an extension */
-extern int ip6t_ext_hdr(u8 nexthdr);
+static inline int
+ip6t_ext_hdr(u8 nexthdr)
+{ return (nexthdr == IPPROTO_HOPOPTS) ||
+ (nexthdr == IPPROTO_ROUTING) ||
+ (nexthdr == IPPROTO_FRAGMENT) ||
+ (nexthdr == IPPROTO_ESP) ||
+ (nexthdr == IPPROTO_AH) ||
+ (nexthdr == IPPROTO_NONE) ||
+ (nexthdr == IPPROTO_DSTOPTS);
+}
+
/* find specified header and get offset to it */
extern int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
int target, unsigned short *fragoff);
diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c
index 94874b0..9d4e155 100644
--- a/net/ipv6/netfilter/ip6_tables.c
+++ b/net/ipv6/netfilter/ip6_tables.c
@@ -78,19 +78,6 @@ EXPORT_SYMBOL_GPL(ip6t_alloc_initial_table);
Hence the start of any table is given by get_table() below. */
-/* Check for an extension */
-int
-ip6t_ext_hdr(u8 nexthdr)
-{
- return (nexthdr == IPPROTO_HOPOPTS) ||
- (nexthdr == IPPROTO_ROUTING) ||
- (nexthdr == IPPROTO_FRAGMENT) ||
- (nexthdr == IPPROTO_ESP) ||
- (nexthdr == IPPROTO_AH) ||
- (nexthdr == IPPROTO_NONE) ||
- (nexthdr == IPPROTO_DSTOPTS);
-}
-
/* Returns whether matches rule or not. */
/* Performance critical - called for every packet */
static inline bool
@@ -2366,7 +2353,6 @@ int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
EXPORT_SYMBOL(ip6t_register_table);
EXPORT_SYMBOL(ip6t_unregister_table);
EXPORT_SYMBOL(ip6t_do_table);
-EXPORT_SYMBOL(ip6t_ext_hdr);
EXPORT_SYMBOL(ipv6_find_hdr);
module_init(ip6_tables_init);
--
1.7.2.5
^ permalink raw reply related
* [PATCH 5/5] netfilter: nf_conntrack: fix incorrect logic in nf_conntrack_init_net
From: pablo @ 2012-04-10 12:49 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1334062141-3962-1-git-send-email-pablo@netfilter.org>
From: Gao feng <gaofeng@cn.fujitsu.com>
in function nf_conntrack_init_net,when nf_conntrack_timeout_init falied,
we should call nf_conntrack_ecache_fini to do rollback.
but the current code calls nf_conntrack_timeout_fini.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_conntrack_core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 3cc4487..729f157 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1592,7 +1592,7 @@ static int nf_conntrack_init_net(struct net *net)
return 0;
err_timeout:
- nf_conntrack_timeout_fini(net);
+ nf_conntrack_ecache_fini(net);
err_ecache:
nf_conntrack_tstamp_fini(net);
err_tstamp:
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH 0/2] adding tracepoints to vhost
From: Stefan Hajnoczi @ 2012-04-10 12:54 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, netdev, linux-kernel, virtualization
In-Reply-To: <20120410124250.GB29808@redhat.com>
On Tue, Apr 10, 2012 at 1:42 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Tue, Apr 10, 2012 at 12:40:50PM +0100, Stefan Hajnoczi wrote:
>> On Tue, Apr 10, 2012 at 3:58 AM, Jason Wang <jasowang@redhat.com> wrote:
>> > To help in vhost analyzing, the following series adding basic tracepoints to
>> > vhost. Operations of both virtqueues and vhost works were traced in current
>> > implementation, net code were untouched. A top-like satistics displaying script
>> > were introduced to help the troubleshooting.
>> >
>> > TODO:
>> > - net specific tracepoints?
>> >
>> > ---
>> >
>> > Jason Wang (2):
>> > vhost: basic tracepoints
>> > tools: virtio: add a top-like utility for displaying vhost satistics
>> >
>> >
>> > drivers/vhost/trace.h | 153 ++++++++++++++++++++
>> > drivers/vhost/vhost.c | 17 ++
>> > tools/virtio/vhost_stat | 360 +++++++++++++++++++++++++++++++++++++++++++++++
>> > 3 files changed, 528 insertions(+), 2 deletions(-)
>> > create mode 100644 drivers/vhost/trace.h
>> > create mode 100755 tools/virtio/vhost_stat
>>
>> Perhaps this can replace the vhost log feature? I'm not sure if
>> tracepoints support the right data types but it seems like vhost
>> debugging could be done using tracing with less code.
>>
>> Stefan
>
> vhost log is not a debugging tool, it logs memory accesses for
> migration.
Thanks. I totally misunderstood its purpose.
Stefan
^ permalink raw reply
* Re: [PATCH 0/2] adding tracepoints to vhost
From: Zhi Yong Wu @ 2012-04-10 13:10 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtualization, linux-kernel, kvm, netdev
In-Reply-To: <20120410124250.GB29808@redhat.com>
On Tue, Apr 10, 2012 at 8:42 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Tue, Apr 10, 2012 at 12:40:50PM +0100, Stefan Hajnoczi wrote:
>> On Tue, Apr 10, 2012 at 3:58 AM, Jason Wang <jasowang@redhat.com> wrote:
>> > To help in vhost analyzing, the following series adding basic tracepoints to
>> > vhost. Operations of both virtqueues and vhost works were traced in current
>> > implementation, net code were untouched. A top-like satistics displaying script
>> > were introduced to help the troubleshooting.
>> >
>> > TODO:
>> > - net specific tracepoints?
>> >
>> > ---
>> >
>> > Jason Wang (2):
>> > vhost: basic tracepoints
>> > tools: virtio: add a top-like utility for displaying vhost satistics
>> >
>> >
>> > drivers/vhost/trace.h | 153 ++++++++++++++++++++
>> > drivers/vhost/vhost.c | 17 ++
>> > tools/virtio/vhost_stat | 360 +++++++++++++++++++++++++++++++++++++++++++++++
>> > 3 files changed, 528 insertions(+), 2 deletions(-)
>> > create mode 100644 drivers/vhost/trace.h
>> > create mode 100755 tools/virtio/vhost_stat
>>
>> Perhaps this can replace the vhost log feature? I'm not sure if
>> tracepoints support the right data types but it seems like vhost
>> debugging could be done using tracing with less code.
>>
>> Stefan
>
> vhost log is not a debugging tool, it logs memory accesses for
> migration.
Great, it is very appreciated if there's some docs about this
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization
--
Regards,
Zhi Yong Wu
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: David Miller @ 2012-04-10 13:26 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, msink, schwidefsky,
heiko.carstens
In-Reply-To: <20120410152923.15aee4df478d819f167cd4af@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 10 Apr 2012 15:29:23 +1000
> After merging the final tree, today's linux-next build (s390 allmodconfig)
> failed like this:
I just checked in the following which will hopefully cure this,
thanks:
--------------------
wiznet: Fix Kconfig dependencies.
Both drivers need to depend upon HAS_IOMEM, otherwise we
get a build failure on platforms like S390.
All the driver specific config options need to depend upon
the drivers themselves.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/ethernet/wiznet/Kconfig | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/wiznet/Kconfig b/drivers/net/ethernet/wiznet/Kconfig
index 2bb383c..c8291bf 100644
--- a/drivers/net/ethernet/wiznet/Kconfig
+++ b/drivers/net/ethernet/wiznet/Kconfig
@@ -19,6 +19,7 @@ if NET_VENDOR_WIZNET
config WIZNET_W5100
tristate "WIZnet W5100 Ethernet support"
+ depends on HAS_IOMEM
---help---
Support for WIZnet W5100 chips.
@@ -31,6 +32,7 @@ config WIZNET_W5100
config WIZNET_W5300
tristate "WIZnet W5300 Ethernet support"
+ depends on HAS_IOMEM
---help---
Support for WIZnet W5300 chips.
@@ -43,6 +45,7 @@ config WIZNET_W5300
choice
prompt "WIZnet interface mode"
+ depends on WIZNET_W5100 || WIZNET_W5300
default WIZNET_BUS_ANY
config WIZNET_BUS_DIRECT
@@ -69,6 +72,7 @@ endchoice
config WIZNET_TX_FLOW
bool "Use transmit flow control"
+ depends on WIZNET_W5100 || WIZNET_W5300
default y
help
This enables transmit flow control for WIZnet chips.
--
1.7.7.6
^ permalink raw reply related
* Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode
From: John Fastabend @ 2012-04-10 13:27 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: roprabhu, stephen.hemminger, davem, hadi, bhutchings,
jeffrey.t.kirsher, netdev, gregory.v.rose, krkumar2, sri
In-Reply-To: <20120410080916.GB26540@redhat.com>
On 4/10/2012 1:09 AM, Michael S. Tsirkin wrote:
> On Mon, Apr 09, 2012 at 03:00:54PM -0700, John Fastabend wrote:
>> This adds a new macvlan mode MACVLAN_PASSTHRU_NOPROMISC
>> this mode acts the same as the original passthru mode _except_
>> it does not set promiscuous mode on the lowerdev. Because the
>> lowerdev is not put in promiscuous mode any unicast or multicast
>> addresses the device should receive must be explicitely added
>> with the FDB bridge ops. In many use cases the management stack
>> will know the mac addresses needed (maybe negotiated via EVB/VDP)
>> or may require only receiving known "good" mac addresses. This
>> mode with the FDB ops supports this usage model.
>
>
> Looks good to me. Some questions below:
>
>> This patch is a result of Roopa Prabhu's work. Follow up
>> patches are needed for VEPA and VEB macvlan modes.
>
> And bridge too?
>
Yes I called this mode VEB here but this is defined in if_link.h
as IFLA_MACVLAN_MODE_BRIDGE. From a IEEE point of view I think
the macvlan bridge mode acts more like a 802.1Q VEB then a 802.1d
bridge.
> Also, my understanding is that other modes won't need a flag
> like this since they don't put the device in promisc mode initially,
> so no assumptions are broken if we require all addresses
> to be declared, right?
>
correct. But requires extra work to the hash table so the forwarding
works correctly.
> A final question: I think we'll later add a macvlan mode
> that does not flood all multicasts. This would change behaviour
> in an incompatible way so we'll probably need yet another
> flag. Would it make sense to combine this functionality
> with nopromisc so we have less modes to support?
>
For VEPA and bridge modes this makes sense to me. If you want
the flood behavior you can create it by adding the addr to all
the devices or just to a subset of them to get the non-flooding
capabilities.
.John
^ permalink raw reply
* Re: axienet driver copyrights
From: David Miller @ 2012-04-10 13:41 UTC (permalink / raw)
To: monstr; +Cc: ariane.keller, daniel.borkmann, netdev, john.williams, linnj
In-Reply-To: <4F84164C.6000702@monstr.eu>
From: Michal Simek <monstr@monstr.eu>
Date: Tue, 10 Apr 2012 13:15:24 +0200
> David: Would it be possible to ping me everytime when there is any
> patch
> around xilinx ethernet controller.
This is a completely unreasonable request, sorry. The burdon is on
you to watch carefully the netdev list for patches you are interested
in.
^ permalink raw reply
* Re: net: more accurate skb truesize - regression on Microblaze
From: David Miller @ 2012-04-10 13:43 UTC (permalink / raw)
To: monstr; +Cc: eric.dumazet, netdev, john.williams
In-Reply-To: <4F841BB9.2030209@monstr.eu>
From: Michal Simek <monstr@monstr.eu>
Date: Tue, 10 Apr 2012 13:38:33 +0200
> There is long history for ll_temac and axi emac drivers. and if you
> compare
> them they are very similar with similar bugs.
> In our distribution we are using older ll_temac driver where this is
> fixed.
> Performance is much higher if you allocate buffers for actual mtu.
You place an enormous burdon upon us when you ask us to analyze your
performance problems and bugs when using out of tree drivers. Please
do not do this.
^ permalink raw reply
* Re: [PATCH 0/2] adding tracepoints to vhost
From: Michael S. Tsirkin @ 2012-04-10 13:45 UTC (permalink / raw)
To: Zhi Yong Wu; +Cc: virtualization, linux-kernel, kvm, netdev
In-Reply-To: <CAEH94Li0==w=AUKd5WCPMcqxLh=+N6bKttOwrE8y-xuOyPt_QA@mail.gmail.com>
On Tue, Apr 10, 2012 at 09:10:48PM +0800, Zhi Yong Wu wrote:
> >> Perhaps this can replace the vhost log feature? I'm not sure if
> >> tracepoints support the right data types but it seems like vhost
> >> debugging could be done using tracing with less code.
> >>
> >> Stefan
> >
> > vhost log is not a debugging tool, it logs memory accesses for
> > migration.
> Great, it is very appreciated if there's some docs about this
About what? vhost logging? See the comment near the
definition of VHOST_SET_LOG_BASE in vhost.h
> > _______________________________________________
> > Virtualization mailing list
> > Virtualization@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/virtualization
>
>
>
> --
> Regards,
>
> Zhi Yong Wu
^ permalink raw reply
* Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode
From: John Fastabend @ 2012-04-10 13:50 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: roprabhu, stephen.hemminger, davem, hadi, bhutchings,
jeffrey.t.kirsher, netdev, gregory.v.rose, krkumar2, sri
In-Reply-To: <20120410081418.GC26540@redhat.com>
On 4/10/2012 1:14 AM, Michael S. Tsirkin wrote:
> On Tue, Apr 10, 2012 at 11:09:16AM +0300, Michael S. Tsirkin wrote:
>> On Mon, Apr 09, 2012 at 03:00:54PM -0700, John Fastabend wrote:
>>> This adds a new macvlan mode MACVLAN_PASSTHRU_NOPROMISC
>>> this mode acts the same as the original passthru mode _except_
>>> it does not set promiscuous mode on the lowerdev. Because the
>>> lowerdev is not put in promiscuous mode any unicast or multicast
>>> addresses the device should receive must be explicitely added
>>> with the FDB bridge ops. In many use cases the management stack
>>> will know the mac addresses needed (maybe negotiated via EVB/VDP)
>>> or may require only receiving known "good" mac addresses. This
>>> mode with the FDB ops supports this usage model.
>>
>>
>> Looks good to me. Some questions below:
>>
>>> This patch is a result of Roopa Prabhu's work. Follow up
>>> patches are needed for VEPA and VEB macvlan modes.
>>
>> And bridge too?
>>
>> Also, my understanding is that other modes won't need a flag
>> like this since they don't put the device in promisc mode initially,
>> so no assumptions are broken if we require all addresses
>> to be declared, right?
>>
>> A final question: I think we'll later add a macvlan mode
>> that does not flood all multicasts. This would change behaviour
>> in an incompatible way so we'll probably need yet another
>> flag. Would it make sense to combine this functionality
>> with nopromisc so we have less modes to support?
>
> One other question I forgot:
>
[...]
>>>
>>> @@ -344,12 +346,15 @@ static int macvlan_stop(struct net_device *dev)
>>> struct macvlan_dev *vlan = netdev_priv(dev);
>>> struct net_device *lowerdev = vlan->lowerdev;
>>>
>>> + dev_uc_unsync(lowerdev, dev);
>>> + dev_mc_unsync(lowerdev, dev);
>>> +
>>> if (vlan->port->passthru) {
>>> - dev_set_promiscuity(lowerdev, -1);
>>> + if (vlan->mode == MACVLAN_MODE_PASSTHRU)
>>> + dev_set_promiscuity(lowerdev, 1);
>>> goto hash_del;
>>> }
>>>
>>> - dev_mc_unsync(lowerdev, dev);
>>> if (dev->flags & IFF_ALLMULTI)
>>> dev_set_allmulti(lowerdev, -1);
>>>
>>> @@ -399,10 +404,11 @@ static void macvlan_change_rx_flags(struct net_device *dev, int change)
>>> dev_set_allmulti(lowerdev, dev->flags & IFF_ALLMULTI ? 1 : -1);
>
> In the new mode, do we want to have promisc on lowerdev follow whatever
> is set on the macvlan, like we do for allmulti?
> I'm not sure at this point - what do others think?
>
Just to enumerate why you would need this: (1) socket set with
PACKET_MR_MULTICAST and (2) something like mrouted is running
on the macvlan (3) maybe some case I missed?
Don't you need CAP_NET_RAW to set these though anyways? So I
wouldn't think it would be a problem. I assume if a user has
CAP_NET_RAW or UUID 0 they really should be able to set this
up.
.John
^ permalink raw reply
* Re: [PATCH] net: orphan queued skbs if device tx can stall
From: Eric Dumazet @ 2012-04-10 13:52 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, linux-kernel, David S. Miller, Jamal Hadi Salim,
Stephen Hemminger, Jason Wang, Neil Horman, Jiri Pirko,
Jeff Kirsher, Michał Mirosław, Ben Hutchings,
Herbert Xu
In-Reply-To: <20120410124151.GA29808@redhat.com>
On Tue, 2012-04-10 at 15:41 +0300, Michael S. Tsirkin wrote:
> I think it's a bad interface too but it's in a userspace ABI
> now so I suspect we are stuck with it for now. We can try deprecating
> but we can't just drop it.
>
By the way, skb orphaning should already be done in skb_orphan_try(),
not sure why its done again in tun_net_xmit(). Note we perform orphaning
right before giving skb to device on premise it'll be sent (and freed)
in a reasonable amount of time.
With following patch, no more qdisc on top of tun device, yet user can
change the limit (I would be curious to know if anybody changes tun
txqueuelen and why)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index bb8c72c..c4a00cf 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -379,6 +379,7 @@ static int tun_net_close(struct net_device *dev)
static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct tun_struct *tun = netdev_priv(dev);
+ int limit;
tun_debug(KERN_INFO, tun, "tun_net_xmit %d\n", skb->len);
@@ -396,7 +397,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
sk_filter(tun->socket.sk, skb))
goto drop;
- if (skb_queue_len(&tun->socket.sk->sk_receive_queue) >= dev->tx_queue_len) {
+ limit = dev->tx_queue_len ? : TUN_READQ_SIZE;
+ if (skb_queue_len(&tun->socket.sk->sk_receive_queue) >= limit) {
if (!(tun->flags & TUN_ONE_QUEUE)) {
/* Normal queueing mode. */
/* Packet scheduler handles dropping of further packets. */
@@ -521,7 +523,7 @@ static void tun_net_init(struct net_device *dev)
/* Zero header length */
dev->type = ARPHRD_NONE;
dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
- dev->tx_queue_len = TUN_READQ_SIZE; /* We prefer our own queue length */
+ dev->tx_queue_len = 0;
break;
case TUN_TAP_DEV:
@@ -532,7 +534,7 @@ static void tun_net_init(struct net_device *dev)
eth_hw_addr_random(dev);
- dev->tx_queue_len = TUN_READQ_SIZE; /* We prefer our own queue length */
+ dev->tx_queue_len = 0;
break;
}
}
^ permalink raw reply related
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