[Issue 1001159] New: Fixes from FreeBSD IP Stack CVS

[bugzilla-daemon at ecoscentric dot com]

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 on the CC list for the issue.