futures (Re: [net2-wg] Packet interface)

[Omprakash Gnawali]

> > Would we rather design and implement core network protocols on top of
> > the standard send/sendDone interface, or something more like
> > SendPoolEntry?
> 
> So let us try to extract exactly what advantages/flexibility the
> SendPoolEntry is warrantying us, versus the added complexity of
> programming against it.

Rodrigo's last email captures the ongoing discussion on how SP might
take advantage of futures to optimize. I also wanted to quote Philip
from his first email on packet interfaces:

"On one hand, simple, low-rate protocols can work fine with
ActiveMessageC. On the other, the need for better energy efficiency
and protocol cooperation might push things towards a more expressive
and powerful interface.".

Is this interface defition driven by the optimizations that we can do
? From a protocol/application developer perspective, in addition to
the network/link optimizations, does it make it easier or harder to
implement things ? Certainly, this interface is more complex than
send/sendDone. Philip, you and Jonathan probably discussed things this
abstraction might buy us in terms of programming ease for common
patterns while you chalked out the interface ? I would like to hear
them. I can see that the system decrementing futures so that an
application can keep track of outstanding number of packets without
having to declare a global variable and manipulate that as one such
convenience.