From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f196.google.com (mail-wr0-f196.google.com [209.85.128.196]) by dpdk.org (Postfix) with ESMTP id 4D162214A for ; Wed, 15 Mar 2017 11:05:26 +0100 (CET) Received: by mail-wr0-f196.google.com with SMTP id u48so1399513wrc.1 for ; Wed, 15 Mar 2017 03:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vQL3NMhyPTik8RuyfYLsN1yIyooTlZWq7nyRgPgYzg8=; b=Xy6L0ixTfzMmRZUGxe0VlksuHj0zAJ9Xmu8p0Q4pSoWpf+tiDFmq3nPGlX9gaV2POA d+qmc4L6LltiDwV44yIKjH9su6ixQM2N4rDzRn3zGbpsO1RLX//VoBCBU/Gw2ocznP7p b9mowvz4dg/PRsh5vnJoSJoII6GEhaNmL/JE1CTc1LeDR/ww98e2Lr+CSqh4aECDD17b jHZ5VIRUmwaJ0sxdRBFTnWr/w1yHi4dl8ey6J7+Djvww7/MzC9LXHdm60eZCqGeqCSVp dmiX+0qvK5rsnNb1XqLRsTcKw8BEu+/RNwg4JVBgYIXwHI4Ho2DW7xEYkc0D/0X+Gp4F 3Qxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vQL3NMhyPTik8RuyfYLsN1yIyooTlZWq7nyRgPgYzg8=; b=sCaNEIbxsGao3AmfoWF8sea24JhsTwnkX5e/3VJChJ44hKyolRoI22qeNRaRrPzwRu GNT4aPLo6MIZ7fPFh43KJeWT4XZcIKZHEc5Kh9wa7wdyudnReM2mttTQN+z4qci7zfj7 5CKvZhjUQYWTAjwM6bqPstFHxwCcJTwPZF437ezh6Lb5Pe3wUoZkg7YXEDPKcx6xwvvQ JMwbuZGZBgdy5ZwKPTBDwfSnAq1l3FrhgjBL7MGevXYsATbT8R+j7FSH1lgdkrySJQ7+ Jsy9pxDBPrRTO6VIzSd2eMk8UxuODKfpN34fRGbKo1PwL7pHLRyCMqkFSc1HImxQUwtm MpcA== X-Gm-Message-State: AFeK/H2mO3+am2p2612oYc7n275FhISlAfVuhClA4wvaJ28lWlTOAfRUtIXZN+RFzUuAIeoSX+S2oEKojsHmSg== X-Received: by 10.223.162.212 with SMTP id t20mr2079801wra.122.1489572325986; Wed, 15 Mar 2017 03:05:25 -0700 (PDT) MIME-Version: 1.0 Sender: jblunck@gmail.com Received: by 10.28.211.20 with HTTP; Wed, 15 Mar 2017 03:05:25 -0700 (PDT) In-Reply-To: <9c2a3831-11b8-2321-9dd8-0888a44bb876@brocade.com> References: <1489444915-3660-1-git-send-email-ciwillia@brocade.com> <9c2a3831-11b8-2321-9dd8-0888a44bb876@brocade.com> From: Jan Blunck Date: Wed, 15 Mar 2017 11:05:25 +0100 X-Google-Sender-Auth: BERAWe9kdsopTV8ADi2C9brhqH0 Message-ID: To: "Charles (Chas) Williams" Cc: dev , yongwang@vmware.com Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [PATCH] net/vmxnet3: fix queue size changes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 10:05:26 -0000 On Wed, Mar 15, 2017 at 10:45 AM, Charles (Chas) Williams wrote: > > > On 03/15/2017 04:18 AM, Jan Blunck wrote: >> >> On Tue, Mar 14, 2017 at 5:38 PM, Charles (Chas) Williams >> wrote: >>> >>> >>> >>> On 03/14/2017 12:11 PM, Jan Blunck wrote: >>>> >>>> >>>> On Mon, Mar 13, 2017 at 11:41 PM, Charles (Chas) Williams >>>> wrote: >>>>> >>>>> >>>>> If the user reconfigures the queues size, then the previosly allocated >>>>> memzone may potentially be too small. Instead, always free the old >>>>> memzone and allocate a new one. >>>>> >>>>> Fixes: dfaff37fc46d ("vmxnet3: import new vmxnet3 poll mode driver >>>>> implementation") >>>>> >>>>> Signed-off-by: Chas Williams >>>>> --- >>>>> drivers/net/vmxnet3/vmxnet3_rxtx.c | 6 +++--- >>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c >>>>> b/drivers/net/vmxnet3/vmxnet3_rxtx.c >>>>> index 6649c3f..104e040 100644 >>>>> --- a/drivers/net/vmxnet3/vmxnet3_rxtx.c >>>>> +++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c >>>>> @@ -893,8 +893,8 @@ vmxnet3_recv_pkts(void *rx_queue, struct rte_mbuf >>>>> **rx_pkts, uint16_t nb_pkts) >>>>> >>>>> /* >>>>> * Create memzone for device rings. malloc can't be used as the >>>>> physical >>>>> address is >>>>> - * needed. If the memzone is already created, then this function >>>>> returns >>>>> a ptr >>>>> - * to the old one. >>>>> + * needed. If the memzone already exists, we free it since it may have >>>>> been created >>>>> + * with a different size. >>>>> */ >>>>> static const struct rte_memzone * >>>>> ring_dma_zone_reserve(struct rte_eth_dev *dev, const char *ring_name, >>>>> @@ -909,7 +909,7 @@ ring_dma_zone_reserve(struct rte_eth_dev *dev, >>>>> const >>>>> char *ring_name, >>>>> >>>>> mz = rte_memzone_lookup(z_name); >>>>> if (mz) >>>>> - return mz; >>>>> + rte_memzone_free(mz); >>>>> >>>>> return rte_memzone_reserve_aligned(z_name, ring_size, >>>>> socket_id, 0, >>>>> VMXNET3_RING_BA_ALIGN); >>>> >>>> >>>> >>>> Chas, >>>> >>>> Thanks for hunting this one down. Wouldn't the rte_memzone_free() >>>> better fit into vmxnet3_cmd_ring_release() ? >>> >>> >>> >>> I don't care which way it goes. I just did what is basically done in >>> gpa_zone_reserve() to match the "style". Tracking the current ring size >>> and avoiding reallocating a potentially large chunk of memory seems like >>> a better idea. >>> >>>> Also the ring_dma_zone_reserve() could get replaced by >>>> rte_eth_dma_zone_reserve() (see also >>> >>> >>> >>> Yes, it probably should get changed to that along with tracking the size. >> >> >> Why don't we always allocate VMXNET3_RX_RING_MAX_SIZE entries? That >> way we don't need to reallocate on a later queue setup change? > > > That's using more memory than it needs to use. It might break someone's > application > that already runs in some tightly constrained machine. Failing to shrink > the memzone > isn't likely to break anything since they have (apparently) already dealt > with having > less memory available before switching to a smaller queue size. > > Still, it can be a matter for another day. > Other drivers (ixgbe, e1000, ...) always allocate based on the max ring size too. Since the VMXNET3_RX_RING_MAX_SIZE is 4096 I don't think it is a huge waste of memory.