MACSEC and if_msk.c

[Richard PALO]

Having [unfortunately] reserved a HP probook 4515s for NetBSD, I
immediately needed to attack a solution for the Marvel Yukon-II Extreme
88E8072 NIC.

I'm coming across an issue where I guess I could use a crash course
NetBSD NIC driver design document, in particular around MACSEC, as

if (sc->sk_type == SK_YUKON_EX)
SK_IF_WRITE_4(sc_if, 0, SK_GMAC_CTRL, SK_GMAC_BYP_RETX_ON);

is okay but adding what FreeBSD does crashes the system, that is

'| SK_GMAC_BYP_MACSECRX_ON | SK_GMAC_BYP_MACSECTX_ON'
SK_IF_WRITE_4(sc_if,0,SK_RXMF1_CTRL_TEST,SK_RFCTL_RX_MACSEC_FLUSH_OFF);

That is, I'm not yet extremely familiar with the different players in
this driver tree, msk, sk, macphy (here, 88E1149), etc...

Also, I understand there is no checksum offloading, is this being worked
on by someone? Is there a NetBSD maintainer for this code that I could
solicit some specific hints?

So far I'm able to configure and bring up the interface but need to get
the bits flowing correctly after a completing all the necessary
initialisation steps.

Can anyone provide any pointers (or war stories) ?

cheers


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Richard PALO
...
Also, I understand there is no checksum offloading, is this being
worked on by someone? Is there a NetBSD maintainer for this code that
I could solicit some specific hints?

Checksum offloading is present... e.g.:

# ifconfig wm0
wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=2bf80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Tx,UDP6CSUM_Tx>
...

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Richard PALO]

Post by Darren Reed

Post by Richard PALO
...
Also, I understand there is no checksum offloading, is this being
worked on by someone? Is there a NetBSD maintainer for this code that
I could solicit some specific hints?

# ifconfig wm0
wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=2bf80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Tx,UDP6CSUM_Tx>
...
Darren

Okay, I'll look at those sources. Thanks.

The manpage (at the end) indicates that it is unimplemented

Post by Darren Reed
BUGS
This driver is experimental.
Support for checksum offload is unimplemented.
Performance with at least some Marvell-based adapters is poor, especially
on loaded PCI buses or when the adapters are behind PCI-PCI bridges. It
is believed that this is because the Marvell parts have significantly
less buffering than the original SysKonnect cards had.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Richard PALO

Post by Darren Reed

Post by Richard PALO
...
Also, I understand there is no checksum offloading, is this being
worked on by someone? Is there a NetBSD maintainer for this code that
I could solicit some specific hints?

# ifconfig wm0
wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=2bf80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Tx,UDP6CSUM_Tx>
...
Darren

Okay, I'll look at those sources. Thanks.
The manpage (at the end) indicates that it is unimplemented

Post by Darren Reed
BUGS
This driver is experimental.
Support for checksum offload is unimplemented.
Performance with at least some Marvell-based adapters is poor, especially
on loaded PCI buses or when the adapters are behind PCI-PCI bridges. It
is believed that this is because the Marvell parts have
significantly
less buffering than the original SysKonnect cards had

Ah, support for checksum offload varies per NIC driver but the kernel has
support for the feature if the driver writer wants to make use of it.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Richard PALO]

So far I get the following:
# ifconfig -m msk0
msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 18:a9:05:dd:f6:07
media: Ethernet autoselect (1000baseT full-duplex)
status: active
supported Ethernet media:
media none
media 10baseT
media 10baseT mediaopt full-duplex
media 100baseTX
media 100baseTX mediaopt full-duplex
media 1000baseT
media 1000baseT mediaopt full-duplex
media autoselect
inet 192.168.0.15 netmask 0xffffff00 broadcast 192.168.0.255
inet6 fe80::1aa9:5ff:fedd:f607%msk0 prefixlen 64 scopeid 0x1

an extract from dmesg shows (http://www.netbsd.org/~richard/dmesg.txt):

~/src/netbsd$ grep msk dmesg.txt
mskc0 at pci2 dev 0 function 0, Yukon-2 Extreme rev. B0 (0x2): ioapic0
pin 16
msk0 at mskc0 port A: Ethernet address 18:a9:05:dd:f6:07
msk_jumbo_buf = 0xffff800043ff3000
makphy0 at msk0 phy 0: Marvell 88E1149 Gigabit PHY, rev. 1
msk0: link state DOWN (was UNKNOWN)
msk0: link state UP (was DOWN)

Unfortunately, still no external access (ping et al) so far ...

I haven't tinkered with the chksum bits yet nor, for what the Yukon-II
Extreme family is concerned, the V2 DESC bits...
Seems some useful info found perusing the linux sky2 driver, though.

I noticed somebody else using amd64 had some issues (35711), I'm curious
if I should first get i386 going before testing amd64.

concerning MACSEC, I noticed this in a freebsd commit

~ if_msk.c

Remove holdover XMAC II writes/reads inherited from sk as
they aren't required and cause problems like the 88E8072
hard locking a system when enabling macsec bypass.
Tested on 8053/8072 by me and 8021 by kettenis.

~ if_skreg.h ~ if_msk.c

Bypass macsec on extreme/supreme based chips.
Makes my 88E8072 work.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de