lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #29361] ip_frag has problems with zero-copy DMA MACs


From: Simon Goldschmidt
Subject: [lwip-devel] [bug #29361] ip_frag has problems with zero-copy DMA MACs
Date: Sat, 27 Mar 2010 17:54:02 +0000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2

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

                 Summary: ip_frag has problems with zero-copy DMA MACs
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Sa 27 Mär 2010 17:54:02 GMT
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: CVS Head

    _______________________________________________________

Details:

This is kind of a duplicate to bug #29271 (Application can't re-use pbufs),
but it's in the stack, not in applications, and we need to remember to fix
it.

A zero-copy MAC that uses DMA might not have fully transmitted a packet when
netif->output returns. In that case, it should probably increase the pbuf's
ref-count and decrease it when done. This conflicts with both:
a)IP_FRAG_USES_STATIC_BUF==1 where one single static buffer is used as well
as
b) IP_FRAG_USES_STATIC_BUF==0 where a (new) PBUF_REF points at the data to
send but the ref-count of the initial pbuf isn't increased (thus it would be
freed right after ip_frag returns)

Fixing a) is easy as long as we are OK with allocating a new PBUF_RAM here
instead of a static buffer (we do a memcpy in both cases, plus on low-memory
systems, IP_FRAG is probably turned off, anyway).

Fixing b) is not that easy: we would have to increase the ref-count of the
original pbuf and decrease it again when the last PBUF_REF is freed. We might
need a "custom" pbuf type here, that can call specific code on actually
freeing a pbuf - or some kind of "chained" pbuf_free...

Any ideas? The current code is only safe on non-DMA systems.




    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]