[ipxe-devel] PXENV_UDP_WRITE

[Frediano Ziglio]

On Tue, 2012-03-13 at 13:19 +0000, Michael Brown wrote:
> On Monday 12 Mar 2012 18:09:19 Frediano Ziglio wrote:
> > Your patch queue packets and transmit if an ARP arrive. The problem is
> > that it change the behaviour of ipv4_tx. Previously it returns failure
> > if ARP was not there and client have to send again packet, now it
> > returns success. Assume you are sending a udp (or even tcp) packet you
> > end up sending multiple packets. Also how to detect when arp is success
> > and packet has been sent?
> 
> The upper-level protocol (TCP or something on top of UDP) must use its own 
> logic to handle retransmissions.  It has to do this anyway, since even if a 
> packet is transmitted successfully onto the wire, there's no guarantee that it 
> reached the recipient.
> 
> The ARP queue is basically a performance optimisation, since it avoids the 
> need to always retransmit in the very common case of trying to send the first 
> unicast packet.
> 
> > I tested PXENV_UDP_WRITE behaviour on physical card (one Intel, one
> > Broadcom) and it blocks till packet is sent or you get an error (ARP
> > timeout for instance). My patch change this behaviour (iPXE code is not
> > blocking).
> 
> This behaviour seems to be fundamentally broken, since it cannot avoid 
> discarding UDP packets that may be received while waiting for the ARP reply.
> 

That's true, but we don't write specifications. Yes, currently
specifications does not specify blocking or not but reference
implementation (Intel ones I think) is blocking.

> 
> If you have code that requires PXENV_UDP_WRITE to block, and treats a 
> successful return status as meaning "packet has been successfully received by 
> the remote recipient", then that code is broken.  UDP is unreliable by design: 
> anything using PXENV_UDP_WRITE has to include some logic to handle 
> retransmissions.
> 
> What is your motivation for wanting PXENV_UDP_WRITE to block?
> 
> Michael

Here at Citrix we support a product called PVS (Provisioning System)
that has software that allow pc to download disk images while booting.
The part of software that handle PXE booting expects this UDP behaviour.

I think your patch is an improve cause packet get transmitted just after
the ARP reply arrives. But caller should know that this packet as been
queued in order to avoid trying sending a new one.
Also ARP should know that client does not want to send packet anymore
and dequeue the packet.

I tried to combine both patches but got bad results.

Frediano