This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Issue 1001159] New: Fixes from FreeBSD IP Stack CVS
- From: bugzilla-daemon at ecoscentric dot com
- To: unassigned at bugs dot ecos dot sourceware dot org
- Date: Tue, 22 Feb 2011 00:30:05 +0000
- Subject: [Issue 1001159] New: Fixes from FreeBSD IP Stack CVS
- Auto-submitted: auto-generated
Please do not reply to this email. Use the web interface provided at:
http://bugzilla.ecoscentric.com/show_bug.cgi?id=1001159
Summary: Fixes from FreeBSD IP Stack CVS
Product: eCos
Version: CVS
Platform: All
OS/Version: Other
Status: UNCONFIRMED
Severity: enhancement
Priority: low
Component: TCP/IP
AssignedTo: unassigned@bugs.ecos.sourceware.org
ReportedBy: kelvinl@users.sf.net
CC: ecos-bugs@ecos.sourceware.org
Class: Advice Request
Created an attachment (id=1145)
--> (http://bugzilla.ecoscentric.com/attachment.cgi?id=1145)
FreeBSD CVS patch
Attached two IP stack fixes from FreeBSD CVS which have not yet made it into
the eCos tree. Both of them are useful for limiting the potential usage of
network buffers under certain circumstances.
The ARP patch prevents the creation of reciprocal ARP cache entries if the
peer's source address is not on a local subnet. These reciprocal ARP cache
entries are created whenever a device on the local link makes contact via ARP,
and each entry uses up network buffers in the routing table. Prior to this fix
in the FreeBSD stack (and in eCos) it did not check the source IP address was
on the local subnet and added the route anyway. This change from FreeBSD's CVS
(r1.108) only adds reciprocal entries for devices with IP addresses on the
local subnet.
The TCP patch provides a configurable upper limit on the number of segments
which can be in the TCP reassembly queue. Without the patch it is possible for
all network buffers to be consumed by TCP reassembly queues when one or more
TCP segments is missing. The basic function of the patch is to set a threshold
over which further TCP reassembly segments will be dropped. This will prevent
further communication where reassembly is necessary (which will be the case
anyway when network buffers have run out), but still allow through packets
where reassembly is not required. As long as the threshold is lower than the
number of network buffers, then the TCP reassembly queues will not be able to
consume the full pool of network buffers.
The patch adds a new option to the FreeBSD CDL (CYGPKG_NET_TCP_REASS_LIMIT)
which enables or disables the reassembly threshold feature. This defaults off
because the new behaviour might be unexpected to those synchronising with the
public repo. Once enabled you can use the CDL option
CYGPKG_NET_TCP_REASS_DIVISOR to set the maximum portion of network buffers
which can be consumed by the TCP reassembly queue. The limit is calculated as
"nmbclusters / CYGPKG_NET_TCP_REASS_DIVISOR", which defaults to 1/16th of the
available nmbclusters. This was the portion used in the original FreeBSD
change, but might be a little small for some embedded systems with very limited
packet buffer space.
Thanks,
Kelvin Lawson.
--
Configure issuemail: http://bugzilla.ecoscentric.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the issue.