From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54232) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agZeT-0004xZ-Jg for qemu-devel@nongnu.org; Thu, 17 Mar 2016 11:15:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agZeQ-00067l-6x for qemu-devel@nongnu.org; Thu, 17 Mar 2016 11:15:53 -0400 References: <1458130611-17304-1-git-send-email-thuth@redhat.com> <1458130611-17304-3-git-send-email-thuth@redhat.com> <20160317062307.GO9032@voom> <56EA5D07.3000706@redhat.com> From: Thomas Huth Message-ID: <56EACA1A.9090104@redhat.com> Date: Thu, 17 Mar 2016 16:15:38 +0100 MIME-Version: 1.0 In-Reply-To: <56EA5D07.3000706@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pex1T5qQVkfDhgq95aowL5GA27mW9lEOO" Subject: Re: [Qemu-devel] [PATCH 2/3] hw/net/spapr_llan: Fix receive buffer handling for better performance List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: lvivier@redhat.com, Alexey Kardashevskiy , Jason Wang , qemu-devel@nongnu.org, Alexander Graf , qemu-ppc@nongnu.org, Anton Blanchard This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pex1T5qQVkfDhgq95aowL5GA27mW9lEOO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17.03.2016 08:30, Thomas Huth wrote: > On 17.03.2016 07:23, David Gibson wrote: >> On Wed, Mar 16, 2016 at 01:16:50PM +0100, Thomas Huth wrote: >>> >>> This patch introduces an alternate way of handling the receive >>> buffers of the spapr-vlan device, resulting in much better >>> receive performance for the guest. [...] >>> +/** >>> + * Enqueuing receive buffer by adding it to one of our receive buffe= r pools >>> + */ >>> +static target_long spapr_vlan_add_rxbuf_to_pool(VIOsPAPRVLANDevice *= dev, >>> + target_ulong buf) >>> +{ >>> + int size =3D VLAN_BD_LEN(buf); >>> + int pool; >>> + >>> + pool =3D spapr_vlan_get_rx_pool_id(dev, size); >>> + >>> + /* No matching pool found? Try to create a new one */ >>> + if (pool < 0) { >>> + for (pool =3D RX_MAX_POOLS - 1; pool >=3D 0 ; pool--) { >> >> I don't think this loop actually accomplishes anything. Either the >> last slot is free, in which case you use it, then sort into place, or >> it's not, in which case you've hit the maximum number of buffer pools.= >=20 > Oh, you're right. Well spotted! I'll rework my patch to do it without > that loop. Wait, no, there was a case where this loop is actually really required: 1) All pools are in use and filled with at least one BD 2) User in the guest suddenly decides to change the buffer size of one of the pools in the /sys fs of the guest. 3) Guest driver tries to add buffers with a new size that do not match any size of one of the pools in the host 4) After the pool on the host runs empty which contained the BDs with the size that is not in use anymore, we should recycle that pool for the buffers with the new size instead. Since that buffer pool might not be at the end of the list, we've got to scan all buffers here to make sure we find it. So I think the for-loop should stay as it is. Thomas --pex1T5qQVkfDhgq95aowL5GA27mW9lEOO 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.0.22 (GNU/Linux) iQIcBAEBAgAGBQJW6soeAAoJEC7Z13T+cC21WfEP/RrJzwHNLW1fMSjZkC4IlZe6 blhUjixdCeeAt5fDUiMQFcZGzP/tWrzwXAwQhoEKSIKMPJl+v6KKOk1nBB9ptUlA oFc/eVaZeXuuU3YJlYi0dkU1n7u1HrL93+fZ380E2+fB/ElrBwfeJifuvz/fKF14 mmQFNvAB8XonIFAMjwOJFJulMvglNF1TBl75KX1TtgUadqChpmvYHwW7V/2V2M+E 23Y+s2tLhkj03C/on9jRNnHHKYBVefSPqR9pDXmdD2aW/ttFH0SI1cSZprWGv/nK d0Emlg1e1DC1ckIhdoA1HWFAp6vJmmWp29ax1FV4BUH6zVEXGa7s/nA7eU95kH9c nCVCJIkXsudPiLgyFnwh9DhJDWfZH+4ISvc9DFSkyyZ0/JfhSd/zgT8o1eBcZW6g NnnJp+9zdXNWU7K7pnEfVZLft8pgUDsVN371ZV6Tr5VCia58+X8T59LrITqQm1Qw 6sEFtALOHR6Vwni53t3fapAd068JhVInEiiqZwx+un8e64ShIuyLSRJuQQytL+5D 1Jtb60wW4sr4HXSDvjR5XJHJJtqDJVY4wiGJLKj5JV9m5IgQzSv8b4AlHzH+nCOg dXbsV3F9gl98kO42zL8thCuK51jyuzX39eQ7gtiaNvz9OsD3bobC6SiT/RUMgOZr /490MIbyB2yOEe84qtpB =3Q6Y -----END PGP SIGNATURE----- --pex1T5qQVkfDhgq95aowL5GA27mW9lEOO--