Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Aug 2000 17:01:16 -0700 (PDT)
From:      Archie Cobbs <archie@whistle.com>
To:        jayanth <jayanth@yahoo-inc.com>
Cc:        freebsd-net@FreeBSD.ORG
Subject:   Re: Max data queued for UDP
Message-ID:  <200008030001.RAA28226@bubba.whistle.com>
In-Reply-To: <20000802111412.A29943@yahoo-inc.com> from jayanth at "Aug 2, 2000 11:14:12 am"

next in thread | previous in thread | raw e-mail | index | archive | help
jayanth writes:
> while running some tests for udp with very small packets(25 bytes) 
> I found that the total amount of data that can be queued
> at the socket buffer(just queued, not read) is very limited,
> close to around 4k - 5k bytes. 
> One of the issues is that the driver uses a cluster for
> every data packet, however small the data packet is.
> There is a per socket limit on the total amount of network
> memory that can be used for a socket (sb->sb_mbmax), which
> is typically 256k. There is also a variable that keeps
> count of the total n/w network memory actually used 
> by the socket (sb->mb_cnt). The mb_cnt variable is
> incremented by a cluster + sizeof(mbuf) for every
> incoming packet. So for very small udp packets the total
> no. of packets that can be queued is 
> sb_mbmax / (cluster + mbuf) = 256K / (2048 + 256) = 113 packets.
> At this point, the sbspace() macro declares that there is
> no space in the socket buffer, in terms of n/w memory. 
> (sbmax - sb_mbcnt becomes -ve)
> 
> TCP already has an sbcompress() and I have code that does
> the same for UDP. The code basically compresses the
> data from the cluster into the mbuf and frees the
> cluster, if the data fits in one mbuf. 
> 
> I am a little hesitant to do it in the driver code or
> the ether_input() code as it might do a copy for
> every protocol including tcp.
> 
> feedback, please... 

IMHO, it makes sense to do it for UDP and raw sockets, but not
generically.

When you say "the driver uses a cluster for every data packet,
however small the data packet is" are you referring to a specific
Ethernet driver? If so then that driver is lame. It should at
least have two possibilities: (a) normal mbuf, and (b) cluster.
It's very easy and fast to make that minimal decision.

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008030001.RAA28226>