Marvell YukonII Status Update?

[Christian Brueffer]

On Mon, Jul 03, 2006 at 05:21:04PM +0900, Pyun YongHyeon wrote:
> On Sat, Jul 01, 2006 at 02:54:01AM -0500, Nikolas Britton wrote:
>  > On 7/1/06, Pyun YongHyeon <pyunyh at gmail.com> wrote:
>  > >On Sat, Jul 01, 2006 at 01:33:51AM -0500, Nikolas Britton wrote:
>  > > > On 7/1/06, Pyun YongHyeon <pyunyh at gmail.com> wrote:
>  > > > >On Fri, Jun 30, 2006 at 11:39:14PM -0500, Nikolas Britton wrote:
>  > > > > > On 6/30/06, Pyun YongHyeon <pyunyh at gmail.com> wrote:
>  > > > > > >On Thu, Jun 29, 2006 at 10:53:52PM -0500, Nikolas Britton wrote:
>  > > > > > > > Anyone know what's going on with YukonII support in FreeBSD,
>  > > > > > > > specifically the Marvell chips used in PCI-Express add-on cards?
>  > > > > > > >
>  > > > > > > > Last I checked somebody was developing an experimental driver 
>  > > and
>  > > > > > > > Marvell had just released the code to their FreeBSD 5.x/6.x 
>  > > driver:
>  > > > > > > > mykbsd60x86-8.12.2.3.tar (bindary kmod package)
>  > > > > > > > mykbsd60x86-8.12.1.3-src.tgz (source code)
>  > > > > > > >
>  > > > > > >
>  > > > > > >I don't know current status of the driver. ATM FreeBSD YukonII
>  > > > > > >driver has stability issues and the driver needs big cleanups
>  > > > > > >if we import the driver into src tree. But I wouldn't do the
>  > > > > > >job and I'll spend my spare time to other thing.
>  > > > > > >I know, from my previous experience(sk(4), stge(4)), how
>  > > > > > >difficult to write a driver without a document and how hard to
>  > > > > > >write a correct driver without knowing hardware internals. I'm
>  > > > > > >sure there are many developers eager to write YukonII driver if
>  > > > > > >they can access the hardware documentation. However I think there
>  > > > > > >is no possibility that Marvell releases their chip documentations.
>  > > > > > >
>  > > > > >
>  > > > > > Marvell will give you the docs if you sign an NDA, I know it's 
>  > > stupid
>  > > > > > but I think it's the only way... unless we vote with the wallet... 
>  > > Who
>  > > > > > has PCI-Express gigabit NIC cards that meet the following criteria?:
>  > > > > >
>  > > > > > a) Supported by FreeBSD.
>  > > > > > b) Unencumbered documentation.
>  > > > > > c) Checksum offloading.
>  > > > > >
>  > > > >
>  > > > >There are many PCIe GigE hardwares upported by em(4) or bge/bce(4).
>  > > > >AFAIK the only hardware features not supported by em(4)/bge(4) driver
>  > > > >is TSO. And hardwares supported by em(4) also have a capability to
>  > > > >offload IPv6 checksumming too but it's not yet supported by the driver.
>  > > > >
>  > > >
>  > > > Will TCP Segmentation Offloading help if you already use a 9000 byte
>  > > > mtu, and is it going to be supported, someday, with em(4)/bge(4)?...
>  > > > I'm mostly clueless about TSO.
>  > > >
>  > >
>  > >Since not all hardwares support JUMBO frame and the maximum MTU
>  > >for the JUMBO frame varies among vendors/chipsets TSO would be
>  > >better suited for interoperability.
>  > >
>  > >I'm really want to see TSO support in our drivers. See the
>  > >following URL to see TSO effect in NetBSD wm(4) driver.
>  > >http://marc.theaimsgroup.com/?t=111662994600001&r=1&w=2
>  > >
>  > 
>  > I see... A poor mans jumbo frames, but only works with the sender,
> 
> You may have to get a NIC that supports JUMBO frames on receiver
> too unless your switch/bridge system fragments the JUMBO frames
> into standard MTU frames.
> 
>  > correct? If NetBSD supports it can't we more or less just copy and
>  > paste the code to FreeBSD? I know it's never that simple but...
>  > 
> 
> Yes, we may borrow the code from NetBSD implementation but I can't
> sure we can just copy it. I guess we need careful reexamination
> the TSO effect on our TCP stack.
> 

Be sure to discuss this with Andre, according to page 9 of his
EuroBSDCon paper he has some plans in this area:

http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TCP%20Stack.pdf

- Christian

-- 
Christian Brueffer	chris at unixpages.org	brueffer at FreeBSD.org
GPG Key:	 http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20060703/416350fc/attachment.pgp