Re: [PATCH] net/vmxnet3: fix queue size changes

[Jan Blunck <jblunck@infradead.org>]

On Tue, Mar 14, 2017 at 5:38 PM, Charles (Chas) Williams
<ciwillia@brocade.com> wrote:
>
>
> On 03/14/2017 12:11 PM, Jan Blunck wrote:
>>
>> On Mon, Mar 13, 2017 at 11:41 PM, Charles (Chas) Williams
>> <ciwillia@brocade.com> 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 <ciwillia@brocade.com>
>>> ---
>>>  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?