* Re: [PATCH] net: orphan queued skbs if device tx can stall
From: Michael S. Tsirkin @ 2012-04-10 9:31 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: <1334048100.3126.21.camel@edumazet-glaptop>
On Tue, Apr 10, 2012 at 10:55:00AM +0200, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 11:41 +0300, Michael S. Tsirkin wrote:
> > On Tue, Apr 10, 2012 at 09:55:58AM +0200, Eric Dumazet wrote:
>
> > > In your case I would just not use qdisc at all, like other virtual
> > > devices.
> >
> > I think that if we do this, this also disables gso
> > for the device, doesn't it?
>
> Not at all, thats unrelated.
>
> > If true that would be a problem as this would
> > hurt performance of virtualized setups a lot.
>
> In fact, removing qdisc layer will help a lot, removing a contention
> point.
>
> Anyway, with a 500 packet limit in TUN queue itself, qdisc layer should
> be always empty. Whats the point storing more than 500 packets for a
> device ? Thats a latency killer.
AKA bufferbloat :)
We could try and reduce the TUN queue so that qdisc can drop packets in
an intelligent manner (e.g. choke) but this would conflict with what you
propose, right?
> >
> > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > > index bb8c72c..fd8c7f0 100644
> > > --- a/drivers/net/tun.c
> > > +++ b/drivers/net/tun.c
> > > @@ -396,7 +396,7 @@ 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) {
> > > + if (skb_queue_len(&tun->socket.sk->sk_receive_queue) >= TUN_READQ_SIZE) {
> > > if (!(tun->flags & TUN_ONE_QUEUE)) {
> > > /* Normal queueing mode. */
> > > /* Packet scheduler handles dropping of further packets. */
> >
> > tx_queue_len is controllable by SIOCSIFTXQLEN
> > so we'll need to override SIOCSIFTXQLEN somehow
> > to avoid breaking userspace that actually uses SIOCSIFTXQLEN, right?
>
> Right now, you control with this tx_queue_len both the qdisc limit (if
> pfifo_fast default) and the receive_queue in TUN.
>
> That doesnt seem right to me, and more a hack/side effect.
> Maybe you want to introduce a new setting, only controling receive queue
> limit, and use tx_queue_len for its original meaning.
>
> Then, setting tx_queue_len to 0 permits to remove qdisc layer, as any
> other netdevice.
>
>
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.
And if that happens we get the deadlock back since
tx_queue_len will get set to a non-0 value. Right?
--
MST
^ permalink raw reply
* Re: net: more accurate skb truesize - regression on Microblaze
From: Eric Dumazet @ 2012-04-10 9:38 UTC (permalink / raw)
To: monstr; +Cc: netdev, John Williams, David Miller
In-Reply-To: <4F83FD7A.5010602@monstr.eu>
On Tue, 2012-04-10 at 11:29 +0200, Michal Simek wrote:
> On 04/10/2012 11:24 AM, Eric Dumazet wrote:
> > On Tue, 2012-04-10 at 11:11 +0200, Michal Simek wrote:
> >
> >> ~ # cat /proc/sys/net/ipv4/tcp_rmem
> >> 4096 87380 130048
> >
> > Are they default values, or tuned by admin ?
> >
> > 130048 bytes isnt enough to let TCP open its rcv window.
>
> yep. Default value after powerup. What's wrong with that?
>
> Michal
>
I guess your tcp performance is driven by these numbers mostly.
receive window wont grow above 64K in these case. a tcpdump could
confirm the issue.
Do you have 130000 pages of memory ?
Seems the net/ipv4/tcp.c code is wrong (or the comment is wrong)
Since its not 1/128 but 1/1024 ....
/* Set per-socket limits to no more than 1/128 the pressure threshold */
limit = nr_free_buffer_pages() << (PAGE_SHIFT - 10);
limit = max(limit, 128UL);
max_share = min(4UL*1024*1024, limit);
sysctl_tcp_wmem[0] = SK_MEM_QUANTUM;
sysctl_tcp_wmem[1] = 16*1024;
sysctl_tcp_wmem[2] = max(64*1024, max_share);
sysctl_tcp_rmem[0] = SK_MEM_QUANTUM;
sysctl_tcp_rmem[1] = 87380;
sysctl_tcp_rmem[2] = max(87380, max_share);
^ permalink raw reply
* Re: [PATCH v17 08/15] seccomp: add system call filtering using BPF
From: James Morris @ 2012-04-10 9:48 UTC (permalink / raw)
To: Will Drewry
Cc: Indan Zupancic, Andrew Morton, linux-kernel,
linux-security-module, linux-arch, linux-doc, kernel-hardening,
netdev, x86, arnd, davem, hpa, mingo, oleg, peterz, rdunlap,
mcgrathr, tglx, luto, eparis, serge.hallyn, djm, scarybeasts,
pmoore, corbet, eric.dumazet, markus, coreyb, keescook
In-Reply-To: <CABqD9hYE0S4EL6yH-57SfNs+D8GFKJgWVN21VzXpQmRuh2ow=w@mail.gmail.com>
On Mon, 9 Apr 2012, Will Drewry wrote:
> > seccomp_chk_filter() mirrors sk_chk_filter(). So it refers to
> > "chk", not "check".
>
> I can change it to be written out or leave it matching the networking
> code. Any preferences?
check :-)
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: net: more accurate skb truesize - regression on Microblaze
From: Michal Simek @ 2012-04-10 9:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, John Williams, David Miller
In-Reply-To: <1334050698.3126.30.camel@edumazet-glaptop>
On 04/10/2012 11:38 AM, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 11:29 +0200, Michal Simek wrote:
>> On 04/10/2012 11:24 AM, Eric Dumazet wrote:
>>> On Tue, 2012-04-10 at 11:11 +0200, Michal Simek wrote:
>>>
>>>> ~ # cat /proc/sys/net/ipv4/tcp_rmem
>>>> 4096 87380 130048
>>>
>>> Are they default values, or tuned by admin ?
>>>
>>> 130048 bytes isnt enough to let TCP open its rcv window.
>>
>> yep. Default value after powerup. What's wrong with that?
>>
>> Michal
>>
>
> I guess your tcp performance is driven by these numbers mostly.
>
> receive window wont grow above 64K in these case. a tcpdump could
> confirm the issue.
>
> Do you have 130000 pages of memory ?
128MB memory and 4k page which is 32k pages.
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: net: more accurate skb truesize - regression on Microblaze
From: Eric Dumazet @ 2012-04-10 9:52 UTC (permalink / raw)
To: monstr; +Cc: netdev, John Williams, David Miller
In-Reply-To: <1334050698.3126.30.camel@edumazet-glaptop>
On Tue, 2012-04-10 at 11:38 +0200, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 11:29 +0200, Michal Simek wrote:
> > On 04/10/2012 11:24 AM, Eric Dumazet wrote:
> > > On Tue, 2012-04-10 at 11:11 +0200, Michal Simek wrote:
> > >
> > >> ~ # cat /proc/sys/net/ipv4/tcp_rmem
> > >> 4096 87380 130048
> > >
> > > Are they default values, or tuned by admin ?
> > >
> > > 130048 bytes isnt enough to let TCP open its rcv window.
> >
> > yep. Default value after powerup. What's wrong with that?
> >
> > Michal
> >
>
> I guess your tcp performance is driven by these numbers mostly.
>
> receive window wont grow above 64K in these case. a tcpdump could
> confirm the issue.
>
> Do you have 130000 pages of memory ?
>
> Seems the net/ipv4/tcp.c code is wrong (or the comment is wrong)
>
> Since its not 1/128 but 1/1024 ....
>
>
> /* Set per-socket limits to no more than 1/128 the pressure threshold */
> limit = nr_free_buffer_pages() << (PAGE_SHIFT - 10);
> limit = max(limit, 128UL);
> max_share = min(4UL*1024*1024, limit);
>
> sysctl_tcp_wmem[0] = SK_MEM_QUANTUM;
> sysctl_tcp_wmem[1] = 16*1024;
> sysctl_tcp_wmem[2] = max(64*1024, max_share);
>
> sysctl_tcp_rmem[0] = SK_MEM_QUANTUM;
> sysctl_tcp_rmem[1] = 87380;
> sysctl_tcp_rmem[2] = max(87380, max_share);
>
OK there is a bug introduced in commit
c43b874d5d714f271b80d4c3f49e05d0cbf51ed2
(tcp: properly initialize tcp memory limits)
I'll send a patch to change :
limit = nr_free_buffer_pages() << (PAGE_SHIFT - 10);
back to
limit = nr_free_buffer_pages() << (PAGE_SHIFT - 7);
You could try this :)
^ permalink raw reply
* [PATCH] tcp: restore correct limit
From: Eric Dumazet @ 2012-04-10 10:03 UTC (permalink / raw)
To: monstr; +Cc: netdev, John Williams, David Miller, Jason Wang, Glauber Costa
In-Reply-To: <1334050698.3126.30.camel@edumazet-glaptop>
Commit c43b874d5d714f (tcp: properly initialize tcp memory limits)
added a regression on machines with low amount of memory, since sockets
cant use 1/128 of memory but 1/1024
Fix this to match comment and previous behavior.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Glauber Costa <glommer@parallels.com>
---
net/ipv4/tcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 5d54ed3..67d726e 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3302,7 +3302,7 @@ void __init tcp_init(void)
tcp_init_mem(&init_net);
/* Set per-socket limits to no more than 1/128 the pressure threshold */
- limit = nr_free_buffer_pages() << (PAGE_SHIFT - 10);
+ limit = nr_free_buffer_pages() << (PAGE_SHIFT - 7);
limit = max(limit, 128UL);
max_share = min(4UL*1024*1024, limit);
^ permalink raw reply related
* Re: net: more accurate skb truesize - regression on Microblaze
From: Michal Simek @ 2012-04-10 10:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, John Williams, David Miller
In-Reply-To: <1334051536.3126.45.camel@edumazet-glaptop>
On 04/10/2012 11:52 AM, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 11:38 +0200, Eric Dumazet wrote:
>> On Tue, 2012-04-10 at 11:29 +0200, Michal Simek wrote:
>>> On 04/10/2012 11:24 AM, Eric Dumazet wrote:
>>>> On Tue, 2012-04-10 at 11:11 +0200, Michal Simek wrote:
>>>>
>>>>> ~ # cat /proc/sys/net/ipv4/tcp_rmem
>>>>> 4096 87380 130048
>>>>
>>>> Are they default values, or tuned by admin ?
>>>>
>>>> 130048 bytes isnt enough to let TCP open its rcv window.
>>>
>>> yep. Default value after powerup. What's wrong with that?
>>>
>>> Michal
>>>
>>
>> I guess your tcp performance is driven by these numbers mostly.
>>
>> receive window wont grow above 64K in these case. a tcpdump could
>> confirm the issue.
>>
>> Do you have 130000 pages of memory ?
>>
>> Seems the net/ipv4/tcp.c code is wrong (or the comment is wrong)
>>
>> Since its not 1/128 but 1/1024 ....
>>
>>
>> /* Set per-socket limits to no more than 1/128 the pressure threshold */
>> limit = nr_free_buffer_pages()<< (PAGE_SHIFT - 10);
>> limit = max(limit, 128UL);
>> max_share = min(4UL*1024*1024, limit);
>>
>> sysctl_tcp_wmem[0] = SK_MEM_QUANTUM;
>> sysctl_tcp_wmem[1] = 16*1024;
>> sysctl_tcp_wmem[2] = max(64*1024, max_share);
>>
>> sysctl_tcp_rmem[0] = SK_MEM_QUANTUM;
>> sysctl_tcp_rmem[1] = 87380;
>> sysctl_tcp_rmem[2] = max(87380, max_share);
>>
>
> OK there is a bug introduced in commit
> c43b874d5d714f271b80d4c3f49e05d0cbf51ed2
> (tcp: properly initialize tcp memory limits)
>
> I'll send a patch to change :
>
> limit = nr_free_buffer_pages()<< (PAGE_SHIFT - 10);
>
> back to
>
> limit = nr_free_buffer_pages()<< (PAGE_SHIFT - 7);
>
>
> You could try this :)
sure.
~ # cat /proc/sys/net/ipv4/tcp_rmem
4096 87380 1040384
Regression is till 5% which is much better on hw design without csum support.
I will also test it with csum support and let you know.
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] net: orphan queued skbs if device tx can stall
From: Eric Dumazet @ 2012-04-10 10:04 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: <20120410093140.GA27651@redhat.com>
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 :(
Packets in qdisc should not be orphaned.
If you think about it, why do we attach skb to socket in the first
place ?
If its not needed for tun, why should it be needed for other devices ?
If TUN has a problem being stopped forever, maybe it should take
appropriate action to flush all packets in qdisc queue after a while, as
this makes no sense to delay packets forever.
^ permalink raw reply
* [PATCH 1/2] l2tp: fix refcount leak in l2tp_ip sockets
From: James Chapman @ 2012-04-10 10:10 UTC (permalink / raw)
To: netdev; +Cc: James Chapman
In-Reply-To: <1334052643-10910-1-git-send-email-jchapman@katalix.com>
The l2tp_ip socket close handler does not update the module refcount
correctly which prevents module unload after the first bind() call on
an L2TPv3 IP encapulation socket.
Signed-off-by: James Chapman <jchapman@katalix.com>
---
net/l2tp/l2tp_ip.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index 55670ec..b56be14 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -232,7 +232,7 @@ static void l2tp_ip_close(struct sock *sk, long timeout)
{
write_lock_bh(&l2tp_ip_lock);
hlist_del_init(&sk->sk_bind_node);
- hlist_del_init(&sk->sk_node);
+ sk_del_node_init(sk);
write_unlock_bh(&l2tp_ip_lock);
sk_common_release(sk);
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/2] l2tp: l2tp_ip socket fixes
From: James Chapman @ 2012-04-10 10:10 UTC (permalink / raw)
To: netdev
A couple of small fixes for the l2tp_ip socket support. This is for
L2TPv3 IP link encapsulation.
[PATCH 1/2] l2tp: fix refcount leak in l2tp_ip sockets
[PATCH 2/2] l2tp: don't overwrite source address in l2tp_ip_bind()
net/l2tp/l2tp_ip.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH 2/2] l2tp: don't overwrite source address in l2tp_ip_bind()
From: James Chapman @ 2012-04-10 10:10 UTC (permalink / raw)
To: netdev; +Cc: James Chapman
In-Reply-To: <1334052643-10910-1-git-send-email-jchapman@katalix.com>
Applications using L2TP/IP sockets want to be able to bind() an L2TP/IP
socket to set the local tunnel id while leaving the auto-assigned source
address alone. So if no source address is supplied, don't overwrite
the address already stored in the socket.
Signed-off-by: James Chapman <jchapman@katalix.com>
---
net/l2tp/l2tp_ip.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index b56be14..585d93e 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -271,7 +271,8 @@ static int l2tp_ip_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
chk_addr_ret != RTN_MULTICAST && chk_addr_ret != RTN_BROADCAST)
goto out;
- inet->inet_rcv_saddr = inet->inet_saddr = addr->l2tp_addr.s_addr;
+ if (addr->l2tp_addr.s_addr)
+ inet->inet_rcv_saddr = inet->inet_saddr = addr->l2tp_addr.s_addr;
if (chk_addr_ret == RTN_MULTICAST || chk_addr_ret == RTN_BROADCAST)
inet->inet_saddr = 0; /* Use device */
sk_dst_reset(sk);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] tcp: restore correct limit
From: Michal Simek @ 2012-04-10 10:14 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, John Williams, David Miller, Jason Wang, Glauber Costa
In-Reply-To: <1334052194.3126.66.camel@edumazet-glaptop>
On 04/10/2012 12:03 PM, Eric Dumazet wrote:
> Commit c43b874d5d714f (tcp: properly initialize tcp memory limits)
> added a regression on machines with low amount of memory, since sockets
> cant use 1/128 of memory but 1/1024
>
> Fix this to match comment and previous behavior.
>
> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> Cc: Jason Wang<jasowang@redhat.com>
> Cc: Glauber Costa<glommer@parallels.com>
> ---
> net/ipv4/tcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 5d54ed3..67d726e 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -3302,7 +3302,7 @@ void __init tcp_init(void)
>
> tcp_init_mem(&init_net);
> /* Set per-socket limits to no more than 1/128 the pressure threshold */
> - limit = nr_free_buffer_pages()<< (PAGE_SHIFT - 10);
> + limit = nr_free_buffer_pages()<< (PAGE_SHIFT - 7);
> limit = max(limit, 128UL);
> max_share = min(4UL*1024*1024, limit);
>
hw design with csum is also much better.
Tested-by: Michal Simek <monstr@monstr.eu>
Thanks for help,
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 v2] wl12xx: fix DMA-API-related warnings
From: Luciano Coelho @ 2012-04-10 10:19 UTC (permalink / raw)
To: Mircea Gherzan
Cc: John W. Linville, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1332006114-30230-1-git-send-email-mgherzan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sat, 2012-03-17 at 18:41 +0100, Mircea Gherzan wrote:
> On the PandaBoard (omap_hsmmc + wl12xx_sdio) with DMA_API_DEBUG:
>
> WARNING: at lib/dma-debug.c:930 check_for_stack.part.8+0x7c/0xe0()
> omap_hsmmc omap_hsmmc.4: DMA-API: device driver maps memory fromstack
>
> Signed-off-by: Mircea Gherzan <mgherzan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
Pushed, thanks for fixing this!
--
Cheers,
Luca.
--
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] tcp: restore correct limit
From: Jason Wang @ 2012-04-10 10:29 UTC (permalink / raw)
To: monstr; +Cc: Eric Dumazet, netdev, John Williams, David Miller, Glauber Costa
In-Reply-To: <4F8407F7.8070703@monstr.eu>
On 04/10/2012 06:14 PM, Michal Simek wrote:
> On 04/10/2012 12:03 PM, Eric Dumazet wrote:
>> Commit c43b874d5d714f (tcp: properly initialize tcp memory limits)
>> added a regression on machines with low amount of memory, since sockets
>> cant use 1/128 of memory but 1/1024
>>
>> Fix this to match comment and previous behavior.
>>
>> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
>> Cc: Jason Wang<jasowang@redhat.com>
>> Cc: Glauber Costa<glommer@parallels.com>
>> ---
>> net/ipv4/tcp.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
>> index 5d54ed3..67d726e 100644
>> --- a/net/ipv4/tcp.c
>> +++ b/net/ipv4/tcp.c
>> @@ -3302,7 +3302,7 @@ void __init tcp_init(void)
>>
>> tcp_init_mem(&init_net);
>> /* Set per-socket limits to no more than 1/128 the pressure
>> threshold */
>> - limit = nr_free_buffer_pages()<< (PAGE_SHIFT - 10);
>> + limit = nr_free_buffer_pages()<< (PAGE_SHIFT - 7);
>> limit = max(limit, 128UL);
>> max_share = min(4UL*1024*1024, limit);
>>
>
> hw design with csum is also much better.
> Tested-by: Michal Simek <monstr@monstr.eu>
>
> Thanks for help,
> Michal
>
>
>
>
>
Hi Michal and Eric:
Which version of kernel did you test, did you try the newest kernel? The
reason I use (PAGE_SHIFT - 10) is in the commit before 3dc43e3, the
limit were calculated with:
limit = nr_free_buffer_pages() / 8;
limit = max(limit, 128UL);
...
limit = ((unsigned long)sysctl_tcp_mem[1]) << (PAGE_SHIFT - 7);
So the rmem should be ok. But there's a defect (which I think does
affect the regression) of my patch would could cause limit that we
should shift after comparing with 128UL like:
limit = nr_free_buffer_pages() / 8;
limit = max(limit, 128UL) << (PAGE_SHIFT - 7);
Is anything I miss?
Thanks
^ permalink raw reply
* Re: [PATCH] tcp: restore correct limit
From: Michal Simek @ 2012-04-10 10:32 UTC (permalink / raw)
To: Jason Wang
Cc: Eric Dumazet, netdev, John Williams, David Miller, Glauber Costa
In-Reply-To: <4F840B99.8040409@redhat.com>
On 04/10/2012 12:29 PM, Jason Wang wrote:
> On 04/10/2012 06:14 PM, Michal Simek wrote:
>> On 04/10/2012 12:03 PM, Eric Dumazet wrote:
>>> Commit c43b874d5d714f (tcp: properly initialize tcp memory limits)
>>> added a regression on machines with low amount of memory, since sockets
>>> cant use 1/128 of memory but 1/1024
>>>
>>> Fix this to match comment and previous behavior.
>>>
>>> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
>>> Cc: Jason Wang<jasowang@redhat.com>
>>> Cc: Glauber Costa<glommer@parallels.com>
>>> ---
>>> net/ipv4/tcp.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
>>> index 5d54ed3..67d726e 100644
>>> --- a/net/ipv4/tcp.c
>>> +++ b/net/ipv4/tcp.c
>>> @@ -3302,7 +3302,7 @@ void __init tcp_init(void)
>>>
>>> tcp_init_mem(&init_net);
>>> /* Set per-socket limits to no more than 1/128 the pressure threshold */
>>> - limit = nr_free_buffer_pages()<< (PAGE_SHIFT - 10);
>>> + limit = nr_free_buffer_pages()<< (PAGE_SHIFT - 7);
>>> limit = max(limit, 128UL);
>>> max_share = min(4UL*1024*1024, limit);
>>>
>>
>> hw design with csum is also much better.
>> Tested-by: Michal Simek <monstr@monstr.eu>
>>
>> Thanks for help,
>> Michal
>>
>>
>>
>>
>>
> Hi Michal and Eric:
>
> Which version of kernel did you test, did you try the newest kernel? The reason I use (PAGE_SHIFT - 10) is in the commit before 3dc43e3, the limit were calculated with:
I have tested it on 3.4.0-rc2.
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 v17 08/15] seccomp: add system call filtering using BPF
From: Eric Dumazet @ 2012-04-10 10:34 UTC (permalink / raw)
To: Indan Zupancic
Cc: Andrew Morton, Will Drewry, linux-kernel, linux-security-module,
linux-arch, linux-doc, kernel-hardening, netdev, x86, arnd, davem,
hpa, mingo, oleg, peterz, rdunlap, mcgrathr, tglx, luto, eparis,
serge.hallyn, djm, scarybeasts, pmoore, corbet, markus, coreyb,
keescook, jmorris
In-Reply-To: <67e30a0c8655fc53a92e8138bba9de66.squirrel@webmail.greenhost.nl>
On Mon, 2012-04-09 at 04:22 +1000, Indan Zupancic wrote:
> On Sat, April 7, 2012 06:23, Andrew Morton wrote:
> >
> > I think this gives userspace an easy way of causing page allocation
> > failure warnings, by permitting large kmalloc() attempts. Add
> > __GFP_NOWARN?
>
> Max is 32kb. sk_attach_filter() in net/core/filter.c is worse,
> it allocates up to 512kb before even checking the length.
>
I dont think so.
sk_attach_filter() uses sk_malloc() and it does a check.
# cat /proc/sys/net/core/optmem_max
20480
Of course you can change the limit on your machine.
^ permalink raw reply
* Re: [PATCH] tcp: restore correct limit
From: Eric Dumazet @ 2012-04-10 10:40 UTC (permalink / raw)
To: Jason Wang; +Cc: monstr, netdev, John Williams, David Miller, Glauber Costa
In-Reply-To: <4F840B99.8040409@redhat.com>
On Tue, 2012-04-10 at 18:29 +0800, Jason Wang wrote:
> On 04/10/2012 06:14 PM, Michal Simek wrote:
> > On 04/10/2012 12:03 PM, Eric Dumazet wrote:
> >> Commit c43b874d5d714f (tcp: properly initialize tcp memory limits)
> >> added a regression on machines with low amount of memory, since sockets
> >> cant use 1/128 of memory but 1/1024
> >>
> >> Fix this to match comment and previous behavior.
> >>
> >> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> >> Cc: Jason Wang<jasowang@redhat.com>
> >> Cc: Glauber Costa<glommer@parallels.com>
> >> ---
> >> net/ipv4/tcp.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> >> index 5d54ed3..67d726e 100644
> >> --- a/net/ipv4/tcp.c
> >> +++ b/net/ipv4/tcp.c
> >> @@ -3302,7 +3302,7 @@ void __init tcp_init(void)
> >>
> >> tcp_init_mem(&init_net);
> >> /* Set per-socket limits to no more than 1/128 the pressure
> >> threshold */
> >> - limit = nr_free_buffer_pages()<< (PAGE_SHIFT - 10);
> >> + limit = nr_free_buffer_pages()<< (PAGE_SHIFT - 7);
> >> limit = max(limit, 128UL);
> >> max_share = min(4UL*1024*1024, limit);
> >>
> >
> > hw design with csum is also much better.
> > Tested-by: Michal Simek <monstr@monstr.eu>
> >
> > Thanks for help,
> > Michal
> >
> >
> >
> >
> >
> Hi Michal and Eric:
>
> Which version of kernel did you test, did you try the newest kernel? The
> reason I use (PAGE_SHIFT - 10) is in the commit before 3dc43e3, the
> limit were calculated with:
>
> limit = nr_free_buffer_pages() / 8;
> limit = max(limit, 128UL);
> ...
> limit = ((unsigned long)sysctl_tcp_mem[1]) << (PAGE_SHIFT - 7);
>
> So the rmem should be ok. But there's a defect (which I think does
> affect the regression) of my patch would could cause limit that we
> should shift after comparing with 128UL like:
>
> limit = nr_free_buffer_pages() / 8;
> limit = max(limit, 128UL) << (PAGE_SHIFT - 7);
>
> Is anything I miss?
>
Yes, probably.
Maybe you should check what was the situation on 2.6 kernels.
Your commit did not completely fix the 4acb41903b2 one
I dont feel its necessary to put in the changelog the complete bug
history, since your commit does the needed tracking.
^ permalink raw reply
* Re: [PATCH 6/6] tilegx network driver: initial support
From: Arnd Bergmann @ 2012-04-10 10:42 UTC (permalink / raw)
To: Chris Metcalf; +Cc: linux-kernel, netdev
In-Reply-To: <4F835510.4060100@tilera.com>
On Monday 09 April 2012, Chris Metcalf wrote:
> On 4/9/2012 9:49 AM, Arnd Bergmann wrote:
> > On Friday 06 April 2012, Chris Metcalf wrote:
> >> This change adds support for the tilegx network driver based on the
> >> GXIO IORPC support in the tilegx software stack, using the on-chip
> >> mPIPE packet processing engine.
> >>
> >> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
> >> ---
> >> drivers/net/ethernet/tile/Kconfig | 1 +
> >> drivers/net/ethernet/tile/Makefile | 4 +-
> >> drivers/net/ethernet/tile/tilegx.c | 2045 ++++++++++++++++++++++++++++++++++++
> >> 3 files changed, 2048 insertions(+), 2 deletions(-)
> >> create mode 100644 drivers/net/ethernet/tile/tilegx.c
> > I think the directory name should be the company, not the architecture here, so make
> > it drivers/net/ethernet/tilera/tilegx.c instead.
>
> This path was picked back when Jeff Kirsher did the initial move into
> drivers/net/ethernet/ for the tilepro driver. I don't have too strong an
> opinion on this; at this point I'm mostly just concerned that it seems like
> potentially not worth the churn to move the files for 3.2, then again for
> 3.5. But if folks agree we should do it, it's fine with me.
Ah, I didn't realize that the directory already exists. It's probably better
not to move it then.
> The actual author would rather not publish his name (I just double-checked
> with him).
Hmm, it doesn't look all that bad actually, the comments I had are just for
small details.
> >> +/* The actual devices. */
> >> +static struct net_device *tile_net_devs[TILE_NET_DEVS];
> >> +
> >> +/* The device for a given channel. HACK: We use "32", not
> >> + * TILE_NET_CHANNELS, because it is fairly subtle that the 5 bit
> >> + * "idesc.channel" field never exceeds TILE_NET_CHANNELS.
> >> + */
> >> +static struct net_device *tile_net_devs_for_channel[32];
> > When you need to keep a list or array of device structures in a driver, you're
> > usually doing something very wrong. The convention is to just pass the pointer
> > around to where you need it.
>
> We need "tile_net_devs_for_channel" because we share a single hardware
> queue for all devices, and each packet's metadata contains a "channel"
> value which indicates the device.
Ok, but please remove tile_net_devs then.
I think a better abstraction for tile_net_devs_for_channel would be
some interface that lets you add private data to a channel so when
you get data from a channel, you can extract that pointer from the driver
using the channel.
Don't you already have a per-channel data structure?
>
> /*
> * The on-chip I/O hardware on tilegx is configured with VA=PA for the
> * kernel's PA range. The low-level APIs and field names use "va" and
> * "void *" nomenclature, to be consistent with the general notion
> * that the addresses in question are virtualizable, but in the kernel
> * context we are actually manipulating PA values. To allow readers
> * of the code to understand what's happening, we direct their
> * attention to this comment by using the following two no-op functions.
> */
> static inline unsigned long pa_to_tile_io_addr(phys_addr_t pa)
> {
> BUILD_BUG_ON(sizeof(phys_addr_t) != sizeof(unsigned long));
> return pa;
> }
> static inline phys_addr_t tile_io_addr_to_pa(unsigned long tile_io_addr)
> {
> return tile_io_addr;
> }
>
> Then the individual uses in the network driver are just things like
> "edesc_head.va = pa_to_tile_io_addr(__pa(va))" or "va =
> __va(tile_io_addr_to_pa((unsigned long)gxio_mpipe_idesc_get_va(idesc)))"
> which I think is a little clearer.
Yes, although I would probably add a typedef for tile_io_addr and pass
the virtual address in and out these helper functions.
For added clarity, you could make the interface look like dma_map_single(),
which requires adding an empty unmap() function as well -- that would
make it obvious where that data is actually used. Why do you require
the reverse map anyway? Normally you only need to pass a bus address to
the device but don't need to translate that back into a virtual address
because you already had that in the beginning.
> >> +/* Allocate and push a buffer. */
> >> +static bool tile_net_provide_buffer(bool small)
> >> +{
> >> [...]
> >> +
> >> + /* Save a back-pointer to 'skb'. */
> >> + *(struct sk_buff **)(skb->data - sizeof(struct sk_buff **)) = skb;
> > This looks very wrong: why would you put the pointer to the skb into the
> > skb itself?
>
> Because we create skbuffs, and then feed the raw underlying buffer storage
> to our hardware, and later, we get back this raw pointer from hardware,
> from which we need to be able to extract the actual skbuff.
Hmm, this sounds very unusual, but I don't really have a better suggestion
here.
> >> + /* Compute the "ip checksum". */
> >> + jsum = isum_hack + htons(s_len - eh_len) + htons(id);
> >> + jsum = __insn_v2sadu(jsum, 0);
> >> + jsum = __insn_v2sadu(jsum, 0);
> >> + jsum = (0xFFFF ^ jsum);
> >> + jh->check = jsum;
> >> +
> >> + /* Update the tcp "seq". */
> >> + uh->seq = htonl(seq);
> >> +
> >> + /* Update some flags. */
> >> + if (!final)
> >> + uh->fin = uh->psh = 0;
> >> +
> >> + /* Compute the tcp pseudo-header checksum. */
> >> + usum = tsum_hack + htons(s_len);
> >> + usum = __insn_v2sadu(usum, 0);
> >> + usum = __insn_v2sadu(usum, 0);
> >> + uh->check = usum;
> > Why to you open-code the ip checksum functions here? Normally the stack takes
> > care of this by calling the functions you already provide in
> > arch/tile/lib/checksum.c
>
> If there is a way to do TSO without this, we'd be happy to hear it, but
> it's not clear how it would be possible. We are only computing a PARTIAL
> checksum here, and letting the hardware compute the "full" checksum.
Sounds like you're looking for csum_partial() ;-)
Arnd
^ permalink raw reply
* Re: [PATCH 2/2] phonet: Sort out initiailziation and cleanup code.
From: Sasha Levin @ 2012-04-10 10:47 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, Eric Dumazet, Eric Van Hensbergen, Dave Jones,
linux-kernel, netdev, Remi Denis-Courmont
In-Reply-To: <m162dctjbo.fsf_-_@fess.ebiederm.org>
On Sat, Apr 7, 2012 at 3:35 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> Recently an oops was reported in phonet if there was a failure during
> network namespace creation.
>
Looks like these two patches fix the problem I've reported.
^ permalink raw reply
* Re: [v2] Re: [RFC] l2tp/ipv6: support for L2TPv2 over UDP over IPv6
From: James Chapman @ 2012-04-10 10:47 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Eric Dumazet, netdev
In-Reply-To: <20120319032807.GD11293@kvack.org>
On 19/03/12 03:28, Benjamin LaHaise wrote:
> On Fri, Mar 16, 2012 at 12:19:02PM +0000, James Chapman wrote:
>> Hi Ben,
>>
>> Do you have an updated patch to test?
>
> Yes, here's an updated version.
We've tested this in several L2TP environments - looks good. Will you be
submitting a version soon?
We have additional patches ready for review which add IPv6 for L2TPv3,
applying on top of your L2TPv2 patch. We also have a patch for iproute2
to add support for unmanaged L2TPv3 ethernet pseudowires over IPv6. They
can be posted when your L2TPv2 patch is submitted, or as an RFC if you
aren't ready to submit your patch yet.
James
^ permalink raw reply
* [PATCH v2] tcp: restore correct limit
From: Eric Dumazet @ 2012-04-10 10:56 UTC (permalink / raw)
To: Jason Wang; +Cc: monstr, netdev, John Williams, David Miller, Glauber Costa
In-Reply-To: <1334054436.3126.80.camel@edumazet-glaptop>
Commit c43b874d5d714f (tcp: properly initialize tcp memory limits) tried
to fix a regression added in commits 4acb4190 & 3dc43e3,
but still get it wrong.
Result is machines with low amount of memory have too small tcp_rmem[2]
value and slow tcp receives : Per socket limit being 1/1024 of memory
instead of 1/128 in old kernels, so rcv window is capped to small
values.
Fix this to match comment and previous behavior.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Glauber Costa <glommer@parallels.com>
---
v2: remove one useless "limit = max(limit, 128UL);" line
net/ipv4/tcp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 5d54ed3..7758a83 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3302,8 +3302,7 @@ void __init tcp_init(void)
tcp_init_mem(&init_net);
/* Set per-socket limits to no more than 1/128 the pressure threshold */
- limit = nr_free_buffer_pages() << (PAGE_SHIFT - 10);
- limit = max(limit, 128UL);
+ limit = nr_free_buffer_pages() << (PAGE_SHIFT - 7);
max_share = min(4UL*1024*1024, limit);
sysctl_tcp_wmem[0] = SK_MEM_QUANTUM;
^ permalink raw reply related
* axienet driver copyrights
From: Michal Simek @ 2012-04-10 11:15 UTC (permalink / raw)
To: Ariane Keller, Daniel Borkmann
Cc: netdev, John Williams, John Linn, David Miller
Dear Ariane and Daniel, [cc: John Linn, John Williams, David Miller and netdev]
I have several questions about one patch which was added to mainline Linux tree.
Below is information about the patch:
drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver
(sha1: 8a3b7a252dca9fb28c23b5bf76c49180a2b60d3b)
The whole driver contains your copyright in 3 files but I don't believe
that you are authors of significant changes to be polite to write there your
copyright.
I really appreciate that someone invested time to add this driver to the mainline
but I am not comfortable that you will be identify as authors of this driver because you are not!
Maintainer for this driver should be Xilinx which has done this driver. I also
see that you have integrated all changes I have done to it. We have done these
changes on Xilinx request to improve the driver stability and performance.
I have spent some time to list your changes you have done to be sure that my
first feeling was wrong but it is not.
There are changes which do nothing with functionality.
1. Clean the driver by checkpatch.pl script.
2. Copy axienet_ior/iow to header file
3. axienet_device_reset resort.
Can you tell me what significant changes you have done in this driver?
I know the whole history of this driver and I have never heard about you
and your changes pointing me that you have just took the latest version
from PetaLogix or Xilinx git repository and use checkpatch.pl script
to fix coding style violations.
I don't think that using checkpatch + 2 simple changes is not enough
to be identified as author.
Can you please correct me?
Thanks,
Michal
David: Would it be possible to ping me everytime when there is any patch
around xilinx ethernet controller. I have all equipment for testing it
and it is my day job to take care about microblaze/xilinx drivers.
--
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] net: orphan queued skbs if device tx can stall
From: Michael S. Tsirkin @ 2012-04-10 11:25 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: <1334052259.3126.68.camel@edumazet-glaptop>
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.
> Packets in qdisc should not be orphaned.
>
> If you think about it, why do we attach skb to socket in the first
> place ?
Good point. The answer is to avoid skb drops for local sockets by
stopping them, right?
> If its not needed for tun, why should it be needed for other devices ?
Maybe needed but it's already broken for tun since the skbs in the
private queue are orphaned by skb_orphan_try?
> If TUN has a problem being stopped forever, maybe it should take
> appropriate action to flush all packets in qdisc queue after a while, as
> this makes no sense to delay packets forever.
>
Well arbitrary timers aren't a solid protection, right?
We get out of stalling transmitters forever but a bad VM can still
degrade performance significantly for others...
----
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) {
--
MST
^ permalink raw reply related
* Re: axienet driver copyrights
From: Daniel Borkmann @ 2012-04-10 11:27 UTC (permalink / raw)
To: monstr; +Cc: Ariane Keller, netdev, John Williams, John Linn, David Miller
In-Reply-To: <4F84164C.6000702@monstr.eu>
On Tue, Apr 10, 2012 at 1:15 PM, Michal Simek <monstr@monstr.eu> wrote:
> Dear Ariane and Daniel, [cc: John Linn, John Williams, David Miller and
> netdev]
>
> I have several questions about one patch which was added to mainline Linux
> tree.
> Below is information about the patch:
>
> drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver
> (sha1: 8a3b7a252dca9fb28c23b5bf76c49180a2b60d3b)
>
> The whole driver contains your copyright in 3 files but I don't believe
> that you are authors of significant changes to be polite to write there your
> copyright.
> I really appreciate that someone invested time to add this driver to the
> mainline
> but I am not comfortable that you will be identify as authors of this driver
> because you are not!
>
> Maintainer for this driver should be Xilinx which has done this driver. I
> also
> see that you have integrated all changes I have done to it. We have done
> these
> changes on Xilinx request to improve the driver stability and performance.
>
> I have spent some time to list your changes you have done to be sure that my
> first feeling was wrong but it is not.
>
> There are changes which do nothing with functionality.
> 1. Clean the driver by checkpatch.pl script.
> 2. Copy axienet_ior/iow to header file
> 3. axienet_device_reset resort.
>
> Can you tell me what significant changes you have done in this driver?
>
> I know the whole history of this driver and I have never heard about you
> and your changes pointing me that you have just took the latest version
> from PetaLogix or Xilinx git repository and use checkpatch.pl script
> to fix coding style violations.
>
> I don't think that using checkpatch + 2 simple changes is not enough
> to be identified as author.
>
> Can you please correct me?
Yes, we mainly spent time to refactor this patch (in particular
removing duplicate code parts), make it work under the latest kernel,
make it kernel coding convention compliant and included it into
Kconfig.
But feel free to remove us from the header, sure, that should be no
problem at all.
I guess we should have CC'ed you when submitting. Sorry that we have
forgotten that.
> Thanks,
> Michal
>
> David: Would it be possible to ping me everytime when there is any patch
> around xilinx ethernet controller. I have all equipment for testing it
> and it is my day job to take care about microblaze/xilinx drivers.
>
>
>
>
> --
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 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
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