Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Dec 2007 20:20:16 +1100
From:      Darren Reed <darrenr@freebsd.org>
To:        Kip Macy <kip.macy@gmail.com>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>, Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org
Subject:   Re: pending changes for TOE support
Message-ID:  <4764EDD0.5050101@freebsd.org>
In-Reply-To: <b1fa29170712151040icb371efseaf61d9b79907b24@mail.gmail.com>
References:  <b1fa29170712121303x537fd11fj4b8827bb353ad8e4@mail.gmail.com>	<b1fa29170712150057m690bd36bm7a1910969e92293b@mail.gmail.com>	<20071215100351.Q70617@fledge.watson.org> <b1fa29170712151040icb371efseaf61d9b79907b24@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Kip Macy wrote:
...
>> My initial feeling is that, even if an interface supports TOE, we shouldn't
>> enable the capability in the enabled vector by default, as TOE bypasses
>> firewall behavior, etc, and would certainly be a surprise if an admin swapped
>> a chelsio card for a non-TOE supporting card.  What's your feeling on this?
> 
> 
> The current implementation bypasses the firewall. This and likely
> other hardware has extensive filtering support so it isn't
> neccessarily intrinsic.

I'm not convinced that we're quite there yet.  There are some important
points that need to be addressed here that basic filtering won't allow:
- reporting on "denied" packets
- interaction with per host/network limits
- interaction with complex pools of addresses

What I would like to see (but I'm not sure if it's possible yet) is the
ability for the TCP MIB to be properly updated with what happens on the
wire - e.g. proper counting of retransmits, timeouts, packet counts, bytes
sent, etc.

>> + * The TOE API assumes that the tcp offload engine can offload the
>> + * the entire connection from set up to teardown, with some provision
>> + * being made to allowing the software stack to handle time wait. If
>> + * the device does not meet these criteria, it is the driver's responsibility
>> + * to overload the functions that it needs to in tcp_usrreqs and make
>> + * its own calls to tcp_output if it needs to do so.
>>
>> While I'm familiar with TCP, I'm less familiar with the scope of what cards
>> support for TOE.  Do we know of any cards that are less capable than the
>> chelsio card in this respect, or are they all sort of on-par on that front?
>> I.e., do we think the above eventuality is likely?
> 
> I don't have any way of knowing. I think it is probably safe to say
> that any vendors that don't meet that criteria now will in the future
> as transistor density increases.

There are cards (or at least I've heard talk of this) that do partial
TCP offload - that is the connection setup and teardown are handled by
the operating system and that only data transfer is offloaded.  I'm in
the wrong country to chase down details on this ;(

I'm given to believe that TSO (transmit segement offload) and RSO
(receive segment offload) are also around.  Both of these should allow
for "packets" of upto 64k to be exchanged with the NIC and for it to
take care of dealing with the MTU sized chunks.

Darren




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4764EDD0.5050101>