[U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet.

[Wolfgang Denk]

Dear Marcel Moolenaar,

In message <CAC78579-738B-4D03-8EF0-14FA1141FAE9 at mac.com> you wrote:
> 
> This is also the crux of the problem. The application
> waits for a specific response, but there's no guarantee
> (due to broadcast or multicast packets on the LAN) that
> the next packet to arrive on the interface is the one
> that we're waiting for.

Right.

> Now, one approach would be to ignore packets that don't
> fit the buffer. This seems unflexible, because it makes
> it impossible to employ flexible buffer allocation in
> the application. What's left? The only thing left is that

"flexible buffer allocation"? May I ask what sort of applications you
have in mind? We're talking about applications running in the context
of a boot loader, right? For anything fancy you should probably rather
use an operating system.

> you return whatever arrived on the interface truncated
> to the buffer size. That way the application can discard
> and call read again if headers don't match, or it can
> allocate a bigger buffer and retry.

Allocate a bigger buffer? What for? The packet has been dropped
already and is not recoverable.

> The problem with this approach is that theoretically
> an application needs to use a buffer that is as large
> as the maximum size of a packet that can appear on the
> interface. For example, with jumbo frames this means
> that any application, module or function that wants to
> receive even the smallest amount of data (say an ARP
> response) needs to allocate a 9K buffer.

Right.

> The question is not of effort -- there's virtually none.
> The question is whether this is good engineering. Worst
> case buffer allocation doesn't strike me as portable nor
> reasonable.

Not portable? In which way do you see any porting  issues  here?  Not
reasonable?  How many such buffers do you need, then? All it takes is
a different size  in  simple  call  to  malloc(),  or  am  I  missing
something?

Please let's keep in mind: this is a boot loader, and a very  minimal
network  stack.  It  is  not an OS, and we don't claim to implement a
TCP/IP stack.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"We shall reach greater and greater platitudes of achievement."
- Richard J. Daley