Date: Sat, 15 Dec 2007 14:46:59 -0800 From: Sam Leffler <sam@errno.com> To: Kevin Oberman <oberman@es.net> Cc: FreeBSD Current <freebsd-current@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support Message-ID: <47645963.40301@errno.com> In-Reply-To: <20071215224101.6D1A045013@ptavv.es.net> References: <20071215224101.6D1A045013@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Oberman wrote:
>> Date: Sat, 15 Dec 2007 14:02:28 -0800
>> From: "Kip Macy" <kip.macy@gmail.com>
>> Sender: owner-freebsd-current@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47645963.40301>