netdev - Re: Socket Buffers and Memory Managment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Jul 2007 22:22:40 +0100
From:	Stephen Hemminger <shemminger@...ux-foundation.org>
To:	Roy Pledge <Roy.Pledge@...escale.com>
Cc:	vinay ravuri <vinaynyc@...oo.com>, netdev@...r.kernel.org
Subject: Re: Socket Buffers and Memory Managment

On Wed, 18 Jul 2007 13:13:21 -0400
Roy Pledge <Roy.Pledge@...escale.com> wrote:

> Stephen Hemminger wrote:
> > 
> > You could play tricks with skb frags but it would be fragile
> > and not worth the trouble. The problem is that the receive
> > skb can stay in the system for a really long time (until the application
> > reads the data) so your fixed size buffer pool in hardware
> > would get exhausted.
> >  
> Perhaps you could elaborate on why this is considered fragile?  It seems to me 
> that as long as proper page management is performed, this mechanism should be 
> stable for processing non-contiguous receive buffers.  I agree that 
> replenishment needs to be addressed, but I see that as an independent issue from 
> using frag lists on receive.

Imagine you had a 4MB receive area. If you used fraglist to point to
the data area, you would still be at risk of receive lock up when you have
all the receive area used up in skb's waiting in the receive queue of the
sockets. You might get it to work if the receive are was very large (ie much
larger than tcp_rmem), but at that point you might as well as be able
to access all of system memory.

Using a DMA I/O engine would help, but you probably won't have one available.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html