Re: nfe driver 6.2 stable



On 27/09/2007, Pyun YongHyeon <pyunyh@xxxxxxxxx> wrote:
On Mon, Sep 24, 2007 at 05:17:40PM +0100, Chris wrote:
> On 24/09/2007, Jeremy Chadwick <koitsu@xxxxxxxxxxx> wrote:
> > On Mon, Sep 24, 2007 at 12:57:23AM +0100, Chris wrote:
> > > nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > > options=8<VLAN_MTU>
> > > inet x.x.x.x netmask 0xffffff00 broadcast x.x.x.x
> > > inet x.x.x.x netmask 0xffffffff broadcast x.x.x.x
> > > ether x
> > > media: Ethernet autoselect (1000baseTX <full-duplex>)
> > > status: active
> > >
> > > 1 - is there a man page for nfe anywhere?
> >
> > Closest thing I can find would be the manpage from -CURRENT's nfe(4),
> > which is supposedly the same code.
> >
> > http://www.freebsd.org/cgi/man.cgi?query=nfe&apropos=0&sektion=0&manpath=FreeBSD+7-current&format=html
> >
> > > 2 - does it support hardware checksum I remember reading it does but
> > > from ifconfig output it appears to not be in use so if it does support
> > > it how do I enable it?
> >
> > It does support it, but I don't know the circumstances surrounding when
> > it gets enabled. That is to say, it's known that some versions of the
> > chip (and/or associated PHY) have bugs, so possibly hardware checksum
> > offloading is known to be broken on the system you're on. Taken from my
> > 7-CURRENT box at home (Asus A8N-E, nForce 4-based):
> >
> > nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> > options=10b<RXCSUM,TXCSUM,VLAN_MTU,TSO4>
> > ether 00:15:f2:17:30:e9
> > inet 192.168.1.51 netmask 0xffffff00 broadcast 192.168.1.255
> > media: Ethernet 1000baseTX <full-duplex>
> > status: active
> >
> > I do not explicitly specify rxcsum or txcsum in my rc.conf ifconfig
> > line.
> >
> > > 3 - same with TOS?
> >
> > TOS (type-of-service) or TSO? If TSO, see above ifconfig.
> >
> > > 4 - how do I enable jumbo frames if it supports it?
> >
> > You should take a bit more itme to read the webpage you obtained the
> > driver from. I see these on the page:
> >
> > 2007/01/06 Added jumbo frame support. [...] Fixed a bug to handle
> > Tx/Rx checksum offload settings with ifconfig.
> > 2006/08/11 Added support for jumbo frame capability.
> >
> > yongari@ (Pyun YongHyeon) should be able to provide additional help
> > with both.
> >
> > > 5 - is it safe to use with zero copy sockets?
> >
> > No idea.
> >
> > > 6 - I currently have both net.isr.direct and mpsafenet disabled is
> > > this driver safe to use on them?
> >
> > No idea.
> >
> > --
> > | Jeremy Chadwick jdc at parodius.com |
> > | Parodius Networking http://www.parodius.com/ |
> > | UNIX Systems Administrator Mountain View, CA, USA |
> > | Making life hard for others since 1977. PGP: 4BD6C0CB |
> >
> >
>
> Ok to recap I have nforce 430 MCP13
>
> I checked the src and current and 6.2-stable driver I am using are the
> same version number but my driver src has this added above tunables.
>
> /* definitions for backporting RELENG-6 */
> #ifndef IFCAP_TSO4
> #define IFCAP_TSO4 0
> #define CSUM_TSO 0
> #endif
> #ifndef VLAN_CAPABILITIES
> #define VLAN_CAPABILITIES(x)
> #endif
> #ifndef IFCAP_VLAN_HWCSUM
> #define IFCAP_VLAN_HWCSUM 0
> #endif
>
> I am guessing If I set the values to 1 I get the features but would
> like someone to confirm this for me before I try it thanks. I only
> have remote access so if it stops the card working I lose access to
> the box.
>

Do you have strong evidence that nForce 430(MCP13, aka MCP51) supports
hardware checksum offload? AFAIK MCP13 does NOT have support checksum
offload/jumbo frame as well as TSO.

If you want to experiment checksum offload capability of MCP13
hardware replace the following line in nfe_attach().

From:
case PCI_PRODUCT_NVIDIA_MCP51_LAN1:
case PCI_PRODUCT_NVIDIA_MCP51_LAN2:
sc->nfe_flags |= NFE_40BIT_ADDR | NFE_PWR_MGMT;
break;

To:
case PCI_PRODUCT_NVIDIA_MCP51_LAN1:
case PCI_PRODUCT_NVIDIA_MCP51_LAN2:
sc->nfe_flags |= NFE_40BIT_ADDR | NFE_PWR_MGMT | NFE_HW_CSUM;
^^^^^^^^^^^^^^
break;

--
Regards,
Pyun YongHyeon


No I didnt know sorry I didnt know MCP13 was aka MCP51 so that
explains why thanks.

Chris
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: Marvell YukonII Status Update?
    ... On Mon, 18 Sep 2006, Pyun YongHyeon wrote: ... support it and commit into the CURRENT)? ... features(VLAN tagging, TSO support, RX checksum offload etc). ... Where can I get the latest version of your driver for fresh ...
    (freebsd-net)
  • Re: Marvell/SysKonnect YukonII source code available
    ... ATM both Linux and OpenBSD use Rx IP checksum offload only ... but this driver enabled Rx checksum offload for TCP/UDP. ... Incomplete bus_dmasupport. ... The driver may not work on big-endian architectures. ...
    (freebsd-net)
  • Re: Marvell/SysKonnect YukonII source code available
    ... ATM both Linux and OpenBSD use Rx IP checksum offload only ... but this driver enabled Rx checksum offload for TCP/UDP. ... Incomplete bus_dmasupport. ... The driver may not work on big-endian architectures. ...
    (freebsd-current)
  • [GIT]: Networking
    ... maintainer making a lot of changes to driver FOO. ... support for networking. ... iwl3945: Fix iwl3945 rate scaling. ... Fix build warning due to typo in %pI4 format changes. ...
    (Linux-Kernel)
  • [GIT]: Networking
    ... Make VLAN and MACVLAN drivers support multiqueue, ... Return type of net driver xmit routines is formalized into ... Lots of bluetooth fixes and cleanups from Marcel Holtmann ... Fix premature termination of FIN_WAIT2, ...
    (Linux-Kernel)