On Wed, Mar 15, 2017 at 10:45 AM, Charles (Chas) Williams
<ciwil...@brocade.com> wrote:
>
>
> On 03/15/2017 04:18 AM, Jan Blunck wrote:
>>
>> On Tue, Mar 14, 2017 at 5:38 PM, Charles (Chas) Williams
>> <ciwil...@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
>>>> <ciwil...@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 <ciwil...@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?
>
>
> 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.
