[dpdk-dev] [RFC 2/4] enic: fix assignment

John Daley (johndale) johndale at cisco.com
Tue Oct 10 19:31:16 CEST 2017


Aaron,

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Aaron Conole
> Sent: Tuesday, September 26, 2017 11:53 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [RFC 2/4] enic: fix assignment
> 
> As it stands, the existing assingment to mbuf has no effect outside of the
> function.  Prior to this change, the mbuf argument would contain an invalid
> address, but it would not be null.  After this change, the caller gets a null
> mbuf back.
> 
> Signed-off-by: Aaron Conole <aconole at redhat.com>
> ---
>  drivers/net/enic/enic_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
> index 40dbec7..ff8e4c5 100644
> --- a/drivers/net/enic/enic_main.c
> +++ b/drivers/net/enic/enic_main.c
> @@ -224,7 +224,7 @@ enic_free_rq_buf(struct rte_mbuf **mbuf)
>  		return;
> 
>  	rte_pktmbuf_free(*mbuf);
> -	mbuf = NULL;
> +	*mbuf = NULL;
>  }
> 
>  void enic_init_vnic_resources(struct enic *enic)

As it turns out, this function is only called when the device is stopped and restarting the device overwrites the mbuf pointers with newly allocated ones, so there is currently no bad behavior. The intent was to NULL out the pointer though and it's certainly better form so I agree with the change.

Reviewed-by: John Daley <johndale at cisco.com>

Thanks,
Johnd
> --
> 2.9.5



More information about the dev mailing list