[lwip-devel] [bug #34427] In RAW/NO_SYS mode, tcp_output may send out large number of ARQ REQ if destination ARP entry has expired

[Min Xu]

URL:
  <http://savannah.nongnu.org/bugs/?34427>

                 Summary: In RAW/NO_SYS mode, tcp_output may send out large
number of ARQ REQ if destination ARP entry has expired
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: maximalmin
            Submitted on: Thu 29 Sep 2011 12:45:27 AM GMT
                Category: TCP
                Severity: 3 - Normal
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: 1.4.0

    _______________________________________________________

Details:

This is related to bug #34426.  So the next two paragraphs are quoted from
that bug report.

We have developed a driver for an integrated EMAC module on the TI DSP that
can achieve a high throughput using RAW / NO_SYS mode. In the following
description, DSP application is the software that is based on the LwIP stack
and the Desktop application is a Win32 application.

In order to maximize that throughput, we increased the receive buffer size on
the desktop application to 65535 (max). When the DSP application sends out
data, it first check the send buffer size available (by calling tcp_sndbuf).
When the returned value is large, the DSP application calls tcp_write (with
TCP_WRITE_FLAG_COPY) with a large payload. The problem however, is that when
the arp entry for the desktop has expired (either because ETHARP_TRUST_IP_MAC
was defined as 0, --OR-- MORE importantly, when there is a lack of network
activity for a while, and the desktop then initiates another transfer), each
of the packet that would've been sent out is then transmitted as an ARP REQ
(for desktop's IP address).

What I like to have changed is that in RAW/NO_SYS (no threads) mode,
tcp_output should be able to check the eventual return code of etharp_output
and that etharp_output should return a new status code like ERR_ARPREQ to
indicate that the packet was not sent, but instead an ARP REQ was sent.  That
way, tcp_output will leave the packet untouched (e.g. not remove it from
unsent list) and return early.  Then the main program loop will get a chance
to POLL the driver and process incoming packets and update the ARP table as
necessary, instead of a multitude of ARP REQ being sent out.

To accomplish this, I believe tcp_segment_output needs to be modified to
return a value, and that as indicated earlier, a new status value should be
added, and returned at the end of the etharp_output function.

-----

On a somewhat unrelated note, when I was implementing the driver to have a
large receive buffer that's friendly to the CACHE (128 byte aligned), I found
it necessary to:

1: not use pbuf mempool: because cache needs to be turned on for performance,
and because the cache is 128 bytes aligned, and because the cache lines
containing the receive buffer must be invalidated since data is DMA
transferred outside of CPU

2: pbuf structs (actually PBUF_ROM is the type I used on received packet) must
add a new field to store the original packet buffer because ICMP PORT NOT
REACHABLE calls pbuf_header to traverse back the header in udp, and
pbuf_header would normally fail on PBUF_ROM types.  -- this is the same as
suggested by Marc Wells 
http://lists.gnu.org/archive/html/lwip-users/2003-03/msg00085.html

3: I upgraded to ver 1.4.0 (from 1.3.1) because I thought there was a
PBUF_CUSTOM type that allows me to call a routine when pbuf_free actually
free'd the buffer, but it turns out this code is written on certain
compilation condition and that it's not normally invoked on any pbuf types. 
The reason I need this is because when the driver has given a "packet" to the
stack, the data in the payload must not change.  However, on high throughput,
it is possible that the underlying receive buffer "slot" gets used again.  So
to remedy that, I mark the slot as used when ever a PBUF_ROM structure is
linked to it in the driver.  And when the pbuf_free is called, this slot is
then marked as free and allowed to be given to the underlying EMAC module in
its receive DMA.

So I believe that it would be nice if the LwIP stack has a conditional flag
that would add these two fields (if others find that an additional 2 words
would cause extra bloat in) pbuf_struct.

Best Regards




    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?34427>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/