From owner-freebsd-net@freebsd.org Mon Aug 8 19:09:01 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EF48BB3706 for ; Mon, 8 Aug 2016 19:09:01 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 307F01C88 for ; Mon, 8 Aug 2016 19:09:01 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.43.134] (86.sub-70-210-231.myvzw.com [70.210.231.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id C2C6B192908; Mon, 8 Aug 2016 19:08:59 +0000 (UTC) Subject: Re: Question about em_irq_fast To: Sreekanth Rupavatharam , "freebsd-net@freebsd.org" References: Cc: Jack Vogel From: Sean Bruno Message-ID: <6dd67a05-d484-593f-98f2-60a062c0daa3@freebsd.org> Date: Mon, 8 Aug 2016 13:08:55 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aWb30hdTn7TuXff9e9UPqVlxH2UqukgVM" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 19:09:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aWb30hdTn7TuXff9e9UPqVlxH2UqukgVM Content-Type: multipart/mixed; boundary="nollQRMNXW4bXjH2sQJk6s6MCfe0sJBoj" From: Sean Bruno To: Sreekanth Rupavatharam , "freebsd-net@freebsd.org" Cc: Jack Vogel Message-ID: <6dd67a05-d484-593f-98f2-60a062c0daa3@freebsd.org> Subject: Re: Question about em_irq_fast References: In-Reply-To: --nollQRMNXW4bXjH2sQJk6s6MCfe0sJBoj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/05/16 12:01, Sreekanth Rupavatharam wrote: > We have this code snippet in em_irq_fast >=20 > ifp =3D > adapter->ifp; =20 >=20 > = =20 >=20 > reg_icr =3D E1000_READ_REG(&adapter->hw, > E1000_ICR); =20 >=20 > = =20 >=20 > /* Hot eject?=20 > */ =20 >=20 > if (reg_icr =3D=3D > 0xffffffff) =20 >=20 > return > FILTER_STRAY; =20 >=20 > = =20 >=20 > /* Definitely not our interrupt.=20 > */ =20 >=20 > if (reg_icr =3D=3D 0x0) >=20 > return FILTER_STRAY; =20 >=20 > I don=E2=80=99t understand why the function returns if the read value i= s 0. From > the programmer=E2=80=99s manual of Intel NIC, I see the following defin= ition. >=20 > =20 >=20 > =20 >=20 > =09 >=20 > =20 >=20 > =09 >=20 > =20 >=20 > =09 >=20 > =20 >=20 > TXDW >=20 > =09 >=20 > 0 >=20 > =09 >=20 > 0b >=20 > =09 >=20 > Transmit Descriptor Written Back=E2=80=A8Set when hardware processes a = transmit > descriptor with the RS bit set (and possibly IDE set). If using delayed= > interrupts (IDE set), the interrupt occurs after the timer expires. >=20 > TXQE >=20 > =09 >=20 > 1 >=20 > =09 >=20 > 0b >=20 > =09 >=20 > Transmit Queue Empty >=20 > Set when the last descriptor block for a transmit queue has been used. >=20 > LSC >=20 > =09 >=20 > 2 >=20 > =09 >=20 > 0b >=20 > =09 >=20 > Link Status Change=E2=80=A8This bit is set each time the link status ch= anges > (either from up to >=20 > down, or from down to up). This bit is affected by the internal link > indication when configured for internal PHY mode. >=20 > RXSEQ >=20 > =09 >=20 > 3 >=20 > =09 >=20 > 0b >=20 > =09 >=20 > Receive Sequence Error=E2=80=A8In TBI mode/internal SerDes1, incoming p= ackets > with a bad delimiter sequence set this bit. In other 802.3 > implementations, this would be classified as a framing error. A valid > sequence consists of:=E2=80=A8idle =EF=82=AE SOF =EF=82=AE data =EF=82=AE= pad (opt) EOF =EF=82=AE fill (opt) =EF=82=AE > idle.=E2=80=A8This is a reserved bit for the *82541xx*, *82547GI/EI*, a= nd > *82540EP/ EM*. Set to 0b. >=20 > RXDMT0 >=20 > =09 >=20 > 4 >=20 > =09 >=20 > 0b >=20 > =09 >=20 > Receive Descriptor Minimum Threshold Reached >=20 > Indicates that the minimum number of receive descriptors are available > and software should load more receive descriptors. >=20 > Reserved >=20 > =09 >=20 > 5 >=20 > =09 >=20 > 0b >=20 > =09 >=20 > Reserved Reads as 0b. >=20 > RXO >=20 > =09 >=20 > 6 >=20 > =09 >=20 > 0b >=20 > =09 >=20 > Receiver Overrun=E2=80=A8Set on receive data FIFO overrun. Could be cau= sed either >=20 > because there are no available receive buffers or because PCI receive > bandwidth is inadequate. >=20 > =20 >=20 > If an interrupt happens due to a normal receive, shouldn=E2=80=99t the = value of > this register be 0 and still be valid? I am seeing this issue on a VM > guest(QEMU hypervisor) where during a flood test, the driver starts > rejecting packets because the register value is 0. Can anyone tell me > if it=E2=80=99s ok or not to remove the check for 0 value ? >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > -Sreekanth >=20 > =20 >=20 Is this with the "lem" driver or the "em" driver under QEMU? Look for "legacy" in the boot output of your VM. sean --nollQRMNXW4bXjH2sQJk6s6MCfe0sJBoj-- --aWb30hdTn7TuXff9e9UPqVlxH2UqukgVM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJXqNjHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k2bUH/A+bI1azGlpc6Vz4K+VoNFb5 fhvDUzII2tyMTFvQEBZJ1kH2MNVDFxEVDvRIV66RZvzw66WBf3U02v9iavVyvYmb wFUgjp/yt0JjjjHmpvEGpSob7j32EXyhMNyOhZL9spI9Fr8CpJS4hcM7Ss7NpEXx GyeGjPkdkw5piG3lyS0oq47G0Z91Wl0LySaFc5odOhmWsvAGa/RZpFe59K/Unj6G KdKm2BCU1mtCuu3Ubbbvk9lp7TM+WKKGZC/5fCP58pQQMRkYhbV9TRPX8IEcLMpP bxEne/z5nOtadINr7QlzliOC1a/Y+n4r+7snW2jLwT5O2je/l4wqqd61sG8mpnk= =Xe7i -----END PGP SIGNATURE----- --aWb30hdTn7TuXff9e9UPqVlxH2UqukgVM--