Re: pending changes for TOE support

On Sat, 15 Dec 2007, Kip Macy wrote:

>> I think it behooves us to find out, given that we're designing a KPI for 
>> those cards also.  I agree with the transistor argument, and given that TOE 
>> is a fairly undeployed technology at this point, it may quickly resolve 
>> itself if it hasn't.
>
> I certainly agree. However, where do you stand if they are unwilling to 
> cooperate?

I think we should make a best faith effort to figure out how to do the right 
thing.  Employing harsh interrogation tactics is probably not called for, but 
we have several vendors who are regularly involved in the FreeBSD community 
and may be willing to lend their insight as to their requirements, even if an 
implementation isn't immediately forthcoming.

>> tcp_output() was previously an internal function of the TCP code, and now 
>> the semantics are being exposed to device drivers.  Let's not perpetuate 
>> poorly documented driver interfaces by adding another one.  I think it 
>> would be a reasonable expectation of a driver author to have consistent 
>> documentation of the life cycle of data structures and objects, locking 
>> expectations and requirements, and the semantics for error values from 
>> functions.  Certainly, they need to look at TCP a fair amount because 
>> they'll be pulling things out of inpcb, tcpcb, etc, but I'd rather we limit 
>> that requirement to simple things (addresses, socket options) that are 
>> relatively static and avoid it being for complex things (locking, error 
>> handling) that tend to be more subject to change.  Also, if you document 
>> what you think the behavior is or should be, we can then check to see if we 
>> agree.
>
> To the extent possible, yes. I'm not convinced that anyone person knows what 
> all the existing invariants are in the stack as it is now. Do you feel that 
> a Stevens'-esque understanding of the environment around the calls is 
> necessary? I know it sounds like "other people beat their wives so I can 
> too", but even something as well documented as ifnet gives no indication of 
> what the locking conventions - e.g. you can't sleep or acquire sx locks in 
> if_ioctl. The demands placed should be no greater than those placed on 
> existing subsystems and should take into account the hitherto somewhat black 
> box nature of TCP.

Actually, what I was asking for in the omitted context above was something 
along the lines of the following, adapted for whatever the reality may be:

   Returning a non-zero value will lead to the software stack beginning a
   disconnect.

Or, say,

   Non-zero return values will be ignored. (*)

This is not intended as a contrarian point.  I'm not looking for a complete 
exposition of the behavior of the stack -- rather, basic information that we 
should be documenting about a KPI, such as what an error being returned will 
do.

Robert N M Watson
Computer Laboratory
University of Cambridge

(*) In which case perhaps it should return void.