netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: "Chopra, Manish" <Manish.Chopra@cavium.com>
Cc: Daniel Borkmann <borkmann@iogearbox.net>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	"bjorn.topel@intel.com" <bjorn.topel@intel.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"Elior, Ariel" <Ariel.Elior@cavium.com>,
	"dsahern@gmail.com" <dsahern@gmail.com>,
	"gospo@broadcom.com" <gospo@broadcom.com>,
	Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@cavium.com>,
	"michael.chan@broadcom.com" <michael.chan@broadcom.com>,
	brouer@redhat.com
Subject: Re: [bpf-next V2 PATCH 05/14] xdp/qede: setup xdp_rxq_info and intro xdp_rxq_info_is_reg
Date: Wed, 27 Dec 2017 12:58:24 +0100	[thread overview]
Message-ID: <20171227125824.629732d0@redhat.com> (raw)
In-Reply-To: <BN3PR0701MB14125CF650672786CAA484BA89070@BN3PR0701MB1412.namprd07.prod.outlook.com>

On Wed, 27 Dec 2017 10:37:10 +0000
"Chopra, Manish" <Manish.Chopra@cavium.com> wrote:

> > -----Original Message-----
> > From: Jesper Dangaard Brouer [mailto:brouer@redhat.com]
> > Sent: Friday, December 22, 2017 10:42 PM
> > To: Daniel Borkmann <borkmann@iogearbox.net>; Alexei Starovoitov
> > <alexei.starovoitov@gmail.com>
> > Cc: bjorn.topel@intel.com; netdev@vger.kernel.org; Jesper Dangaard Brouer
> > <brouer@redhat.com>; Elior, Ariel <Ariel.Elior@cavium.com>;
> > dsahern@gmail.com; gospo@broadcom.com; Dept-Eng Everest Linux L2 <Dept-  
> > EngEverestLinuxL2@cavium.com>; michael.chan@broadcom.com  
> > Subject: [bpf-next V2 PATCH 05/14] xdp/qede: setup xdp_rxq_info and intro
> > xdp_rxq_info_is_reg
> > 
> > The driver code qede_free_fp_array() depend on kfree() can be called with a
> > NULL pointer. This stems from the qede_alloc_fp_array() function which either
> > (kz)alloc memory for fp->txq or fp->rxq.
> > This also simplifies error handling code in case of memory allocation failures,
> > but xdp_rxq_info_unreg need to know the difference.
> > 
> > Introduce xdp_rxq_info_is_reg() to handle if a memory allocation fails and
> > detect this is the failure path by seeing that xdp_rxq_info was not registred yet,
> > which first happens after successful alloaction in qede_init_fp().
> > 
> > Driver hook points for xdp_rxq_info:
> >  * reg  : qede_init_fp
> >  * unreg: qede_free_fp_array
> > 
> > Tested on actual hardware with samples/bpf program.
> > 
> > V2: Driver have no proper error path for failed XDP RX-queue info reg, as
> > qede_init_fp() is a void function.
> > 
> > Cc: everest-linux-l2@cavium.com
> > Cc: Ariel Elior <Ariel.Elior@cavium.com>
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > ---
> >  drivers/net/ethernet/qlogic/qede/qede.h      |    2 ++
> >  drivers/net/ethernet/qlogic/qede/qede_fp.c   |    1 +
> >  drivers/net/ethernet/qlogic/qede/qede_main.c |   10 ++++++++++
> >  include/net/xdp.h                            |    1 +
> >  net/core/xdp.c                               |    6 ++++++
> >  5 files changed, 20 insertions(+)
> > 
> > diff --git a/drivers/net/ethernet/qlogic/qede/qede.h
> > b/drivers/net/ethernet/qlogic/qede/qede.h
> > index a3a70ade411f..62f47736511b 100644
> > --- a/drivers/net/ethernet/qlogic/qede/qede.h
> > +++ b/drivers/net/ethernet/qlogic/qede/qede.h
> > @@ -40,6 +40,7 @@
> >  #include <linux/kernel.h>
> >  #include <linux/mutex.h>
> >  #include <linux/bpf.h>
> > +#include <net/xdp.h>
> >  #include <linux/qed/qede_rdma.h>
> >  #include <linux/io.h>
> >  #ifdef CONFIG_RFS_ACCEL
> > @@ -345,6 +346,7 @@ struct qede_rx_queue {
> >  	u64 xdp_no_pass;
> > 
> >  	void *handle;
> > +	struct xdp_rxq_info xdp_rxq;
> >  };
> > 
> >  union db_prod {
> > diff --git a/drivers/net/ethernet/qlogic/qede/qede_fp.c
> > b/drivers/net/ethernet/qlogic/qede/qede_fp.c
> > index 48ec4c56cddf..dafc079ab6b9 100644
> > --- a/drivers/net/ethernet/qlogic/qede/qede_fp.c
> > +++ b/drivers/net/ethernet/qlogic/qede/qede_fp.c
> > @@ -1006,6 +1006,7 @@ static bool qede_rx_xdp(struct qede_dev *edev,
> >  	xdp.data = xdp.data_hard_start + *data_offset;
> >  	xdp_set_data_meta_invalid(&xdp);
> >  	xdp.data_end = xdp.data + *len;
> > +	xdp.rxq = &rxq->xdp_rxq;
> > 
> >  	/* Queues always have a full reset currently, so for the time
> >  	 * being until there's atomic program replace just mark read diff --git
> > a/drivers/net/ethernet/qlogic/qede/qede_main.c
> > b/drivers/net/ethernet/qlogic/qede/qede_main.c
> > index 57332b3e5e64..24160f1fd0e5 100644
> > --- a/drivers/net/ethernet/qlogic/qede/qede_main.c
> > +++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
> > @@ -762,6 +762,12 @@ static void qede_free_fp_array(struct qede_dev *edev)
> >  			fp = &edev->fp_array[i];
> > 
> >  			kfree(fp->sb_info);
> > +			/* Handle mem alloc failure case where qede_init_fp
> > +			 * didn't register xdp_rxq_info yet.
> > +			 * Implicit only (fp->type & QEDE_FASTPATH_RX)
> > +			 */
> > +			if (fp->rxq && xdp_rxq_info_is_reg(&fp->rxq->xdp_rxq))
> > +				xdp_rxq_info_unreg(&fp->rxq->xdp_rxq);  
> 
> Isn't this sufficient just ?
> If (fp->rxq)
> 	xdp_rxq_info_unreg(&fp->rxq->xdp_rxq);

No, it is not sufficient.

Your driver have qede_alloc_fp_array() which for_each_queue (kz)alloc
memory.  If one of the memory allocations fail, then memory is
free'ed/"rolled-back" in qede_free_fp_array().  Thus, some of the
fp->rxq pointers will be allocated, but xdp_rxq_info_reg() have not
"registered" it yet.  Thus, this _is_ needed to correctly handle memory
failures.

> xdp_rxq_info_is_reg() API seems unnecessary to me,
> xdp_rxq_info_unreg() seems to be taking care of the case if it's not
> registered then WARN already, I think instead of adding these checks
> in individual drivers, better handle it properly in
> xdp_rxq_info_unreg() ?

The xdp_rxq_info_is_reg() API is needed in your driver, and I also found
a need for this in the Broadcom bnxt_en driver.


> >  			kfree(fp->rxq);
> >  			kfree(fp->xdp_tx);
> >  			kfree(fp->txq);
> > @@ -1498,6 +1504,10 @@ static void qede_init_fp(struct qede_dev *edev)
> >  			else
> >  				fp->rxq->data_direction =
> > DMA_FROM_DEVICE;
> >  			fp->rxq->dev = &edev->pdev->dev;
> > +
> > +			/* Driver have no error path from here */
> > +			WARN_ON(xdp_rxq_info_reg(&fp->rxq->xdp_rxq, edev-  
> > >ndev,  
> > +						 fp->rxq->rxq_id) < 0);
> >  		}  
> 
> We will reach to this point only when fp->rxq and edev are valid
> I don't think that xdp_rxq_info_reg() will fail ever in that case.

With the current implementation in xdp.c, I agree that this case will
never fail in your driver.  There is a clear expectation, that this API
will be extended (to support per RX-ring memory "return/free" API) and
that "will-never-fail" assumption will likely change...

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

  reply	other threads:[~2017-12-27 11:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-22 17:11 [bpf-next V2 PATCH 00/14] xdp: new XDP rx-queue info concept Jesper Dangaard Brouer
2017-12-22 17:11 ` [bpf-next V2 PATCH 01/14] xdp: base API for " Jesper Dangaard Brouer
2017-12-23  0:14   ` Jakub Kicinski
2017-12-23 13:13     ` Jesper Dangaard Brouer
2017-12-22 17:11 ` [bpf-next V2 PATCH 02/14] xdp/mlx5: setup xdp_rxq_info Jesper Dangaard Brouer
2017-12-22 17:11 ` [bpf-next V2 PATCH 03/14] i40e: " Jesper Dangaard Brouer
2017-12-22 17:11 ` [bpf-next V2 PATCH 04/14] ixgbe: " Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 05/14] xdp/qede: setup xdp_rxq_info and intro xdp_rxq_info_is_reg Jesper Dangaard Brouer
2017-12-27 10:37   ` Chopra, Manish
2017-12-27 11:58     ` Jesper Dangaard Brouer [this message]
2017-12-22 17:12 ` [bpf-next V2 PATCH 06/14] mlx4: setup xdp_rxq_info Jesper Dangaard Brouer
2017-12-24 11:11   ` Tariq Toukan
2017-12-22 17:12 ` [bpf-next V2 PATCH 07/14] bnxt_en: " Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 08/14] nfp: " Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 09/14] thunderx: " Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 10/14] tun: " Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 11/14] virtio_net: " Jesper Dangaard Brouer
2017-12-26 11:20   ` Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 12/14] xdp: generic XDP handling of xdp_rxq_info Jesper Dangaard Brouer
2017-12-22 17:12 ` [bpf-next V2 PATCH 13/14] bpf: finally expose xdp_rxq_info to XDP bpf-programs Jesper Dangaard Brouer
2017-12-23  4:50   ` Alexei Starovoitov
2017-12-22 17:12 ` [bpf-next V2 PATCH 14/14] samples/bpf: program demonstrating access to xdp_rxq_info Jesper Dangaard Brouer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171227125824.629732d0@redhat.com \
    --to=brouer@redhat.com \
    --cc=Ariel.Elior@cavium.com \
    --cc=Dept-EngEverestLinuxL2@cavium.com \
    --cc=Manish.Chopra@cavium.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bjorn.topel@intel.com \
    --cc=borkmann@iogearbox.net \
    --cc=dsahern@gmail.com \
    --cc=gospo@broadcom.com \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).