Re: ifconfig -v ix0 output delay

In reply to: mike tancsa : "ifconfig -v ix0 output delay"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Kristof Provost <kp_at_FreeBSD.org>
Date: Tue, 26 Sep 2023 09:03:30 UTC
On 25 Sep 2023, at 23:12, mike tancsa wrote:
> Hi All,
>
>     A small annoyance, but I was wondering why "ifconfig -v ix0" seems to take a "long time" compared to other 10G nics.  e.g.
>
>
> 0(nfs3b2)# time ifconfig -v ix0
> ix0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=4e53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
>         ether 0c:c4:7a:6f:20:a0
>         inet6 fe80::ec4:7aff:fe6f:20a0%ix0 prefixlen 64 scopeid 0x1
>         inet6 2607:f3e0:0:6:ec4:7aff:fe6f:20a0 prefixlen 64 autoconf
>         inet 10.255.255.132 netmask 0xffffff00 broadcast 10.255.255.255
>         media: Ethernet autoselect (1000baseT <full-duplex>)
>         status: active
>         nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
> 0.000u 1.251s 0:01.25 100.0%    167+198k 0+0io 0pf+0w
> 0(nfs3b2)#
>
> vs
>
> % time ifconfig -v cxl0
> cxl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=6ec07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6,HWRXTSTMP,NOMAP>
>         ether 00:07:43:60:c4:b0
>         inet 10.251.12.1 netmask 0xffffff00 broadcast 10.251.12.255
>         media: Ethernet 10Gbase-Twinax <full-duplex>
>         status: active
>         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>         plugged: SFP/SFP+/SFP28 Unknown (Copper pigtail)
>         vendor: OEM PN: SFP-H10GB-CU5M SN: S220304060201 DATE: 2022-03-24
> 0.000u 0.002s 0:00.02 0.0%      0+0k 0+0io 0pf+0w
>
>
> Going through truss, the delay seems to be after "ioctl(3,SIOCGIFSTATUS,0x65d9929d0f0)             ERR#22 'Invalid argument'"
>
>
> socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0)        = 6 (0x6)
> ioctl(6,SIOCGIFINDEX,0x65d9929cbf0)              = 0 (0x0)
> close(6)                                         = 0 (0x0)
> ioctl(5,SIOCGDEFIFACE_IN6,0x65d9929cca0)         = 0 (0x0)
> close(5)                                         = 0 (0x0)
>         nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
> write(1,"\tnd6 options=23<PERFORMNUD,ACCE"...,56) = 56 (0x38)
> ioctl(3,SIOCGIFSTATUS,0x65d9929d0f0)             ERR#22 'Invalid argument'
>
>
>
> ioctl(4,SIOCGI2C,0x65d9929ca50)                  = 0 (0x0)

It’s this call. That ends up in ixgbe_read_i2c_byte_generic_int(), where it’ll retry 11 times, taking roughly 100ms per attempt.

I either do not understand how SFP type and presence detection is done, or it’s broken, so I’ve not yet been able to persuade it to be less awful. Ideally the Intel people should take a look at this.

Best regards,
Kristof