pending changes for TOE support

[Sam Leffler]

Kevin Oberman wrote:
>> Date: Sat, 15 Dec 2007 14:02:28 -0800
>> From: "Kip Macy" <kip.macy at gmail.com>
>> Sender: owner-freebsd-current at freebsd.org
>>
>>     
>>> 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.
>>>       
>> :-) - the two vendors that I know of have not been active in the
>> community. Sam has initiated contact on my behalf with the one vendor
>> that might be willing to talk to us. The other vendor has an
>> established pattern of ignoring all requests.
>>
>>     
>>>>> 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.
>>>       
>> That is quite reasonable. I perceived your initial request as being
>> entirely too open-ended.
>>     
>
> We certainly know who provides support for Intel and Myricom cards
> (unless there has been a recent change of which I am unaware) and I
> happen to work across the hall from the guy who has been upgrading the
> Neterion drivers for them and I suspect provided the recent new versions
> to them.
>
> Am I missing anyone?
>
> If they are contacted and express disinterest or don't respond, I think
> Kip has to proceed as best he can.
>
> We use three of the vendors I know of with FreeBSD, so can push as a
> customer, too. We will be ordering more 10GE cards from someone soon and
> support for TOE could be a significant issue in selection. Until now it
> has not been mentioned since there was no prospect of near-term FreeBSD
> support, but that is clearly no longer the case.
>   
So far as I know none of Intel, Myricom, and Neterion support TOE.

    Sam