netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Maciej Fijalkowski <maciejromanfijalkowski@gmail.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
	davem@davemloft.net,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Andrew Bowers <andrewx.bowers@intel.com>,
	bjorn.topel@intel.com, magnus.karlsson@intel.com
Subject: Re: [net-next v2 9/9] ice: allow 3k MTU for XDP
Date: Tue, 5 Nov 2019 18:32:50 +0100	[thread overview]
Message-ID: <20191105183250.000052bd@gmail.com> (raw)
In-Reply-To: <20191105133723.5dbe6aa0@carbon>

On Tue, 5 Nov 2019 13:37:23 +0100
Jesper Dangaard Brouer <brouer@redhat.com> wrote:

> On Mon,  4 Nov 2019 13:51:25 -0800
> Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> 
> > From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> > 
> > At this point ice driver is able to work on order 1 pages that are split
> > onto two 3k buffers. Let's reflect that when user is setting new MTU
> > size and XDP is present on interface.
> > 
> > Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> > Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> > Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> >  drivers/net/ethernet/intel/ice/ice_main.c | 16 ++++++++++++++--
> >  1 file changed, 14 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> > index 29eea08807fd..363b284e8aa1 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_main.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> > @@ -4658,6 +4658,18 @@ static void ice_rebuild(struct ice_pf *pf, enum ice_reset_req reset_type)
> >  	dev_err(dev, "Rebuild failed, unload and reload driver\n");
> >  }
> >  
> > +/**
> > + * ice_max_xdp_frame_size - returns the maximum allowed frame size for XDP
> > + * @vsi: Pointer to VSI structure
> > + */
> > +static int ice_max_xdp_frame_size(struct ice_vsi *vsi)
> > +{
> > +	if (PAGE_SIZE >= 8192 || test_bit(ICE_FLAG_LEGACY_RX, vsi->back->flags))
> > +		return ICE_RXBUF_2048 - XDP_PACKET_HEADROOM;  
> 
> I've not checked the details of the ICE drivers memory model, are you
> using a split-page model?

Yes.

> 
> If so, in case of ICE_FLAG_LEGACY_RX and PAGE_SIZE==4096, then other
> Intel drivers use headroom size 192 bytes and not
> XDP_PACKET_HEADROOM=256, because it doesn't fit with split-page model.

That's not quite right.

What mostly ICE_FLAG_LEGACY_RX does is that it indicates whether we're using
build_skb() or not.

If !ICE_FLAG_LEGACY_RX && PAGE_SIZE==4096, we provide a 192 byte headroom and
320 byte tailroom dedicated for skb_shared_info in order to support the
build_skb(). We can piggy-back on that headroom for XDP purposes, which we're
currently doing in intel drivers.

Otherwise, the legacy Rx flow doesn't provide *any* headroom/tailroom, so to
satisfy the XDP headroom requirement, it needs to be explicitly taken into
account, which is what I'm trying to address in this series, see
ice_rx_offset()@[1].

Seems that i40e is not doing it and I suppose it is broken for case where XDP
prog is enlarging the frame and legacy Rx path is taken. I can later submit
small set with other two issues that came up from Jakub's review on first
revision of this set.

> 
> Asked in another way: Have you taking into account the 320 bytes needed
> by skb_shared_info ?

For legacy Rx there's no particular need for it as __napi_alloc_skb() is
handling it for us (note that legacy Rx implies ice_construct_skb() call where
we get the skb allocated via already mentioned __napi_alloc_skb() and then
memcpy the actual frame contents onto this skb).

Thanks,
Maciej

[1] :
https://lore.kernel.org/netdev/20191104215125.16745-8-jeffrey.t.kirsher@intel.com/

> 
> 
> > +	else
> > +		return ICE_RXBUF_3072;
> > +}
> > +
> >  /**
> >   * ice_change_mtu - NDO callback to change the MTU
> >   * @netdev: network interface device structure
> > @@ -4678,11 +4690,11 @@ static int ice_change_mtu(struct net_device *netdev, int new_mtu)
> >  	}
> >  
> >  	if (ice_is_xdp_ena_vsi(vsi)) {
> > -		int frame_size = ICE_RXBUF_2048 - XDP_PACKET_HEADROOM;
> > +		int frame_size = ice_max_xdp_frame_size(vsi);
> >  
> >  		if (new_mtu + ICE_ETH_PKT_HDR_PAD > frame_size) {
> >  			netdev_err(netdev, "max MTU for XDP usage is %d\n",
> > -				   frame_size);
> > +				   frame_size - ICE_ETH_PKT_HDR_PAD);
> >  			return -EINVAL;
> >  		}
> >  	}  
> 
> 
> 


  reply	other threads:[~2019-11-05 17:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-04 21:51 [net-next v2 0/9][pull request] 100GbE Intel Wired LAN Driver Updates 2019-11-04 Jeff Kirsher
2019-11-04 21:51 ` [net-next v2 1/9] ice: Introduce ice_base.c Jeff Kirsher
2019-11-04 21:51 ` [net-next v2 2/9] ice: get rid of per-tc flow in Tx queue configuration routines Jeff Kirsher
2019-11-04 21:51 ` [net-next v2 3/9] ice: Add support for XDP Jeff Kirsher
2019-11-04 21:51 ` [net-next v2 4/9] ice: Move common functions to ice_txrx_lib.c Jeff Kirsher
2019-11-04 21:51 ` [net-next v2 5/9] ice: Add support for AF_XDP Jeff Kirsher
2019-11-04 21:51 ` [net-next v2 6/9] ice: introduce legacy Rx flag Jeff Kirsher
2019-11-04 21:51 ` [net-next v2 7/9] ice: introduce frame padding computation logic Jeff Kirsher
2019-11-04 21:51 ` [net-next v2 8/9] ice: add build_skb() support Jeff Kirsher
2019-11-04 21:51 ` [net-next v2 9/9] ice: allow 3k MTU for XDP Jeff Kirsher
2019-11-05 12:37   ` Jesper Dangaard Brouer
2019-11-05 17:32     ` Maciej Fijalkowski [this message]
2019-11-05 21:40 ` [net-next v2 0/9][pull request] 100GbE Intel Wired LAN Driver Updates 2019-11-04 David Miller

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=20191105183250.000052bd@gmail.com \
    --to=maciejromanfijalkowski@gmail.com \
    --cc=andrewx.bowers@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=bjorn.topel@intel.com \
    --cc=brouer@redhat.com \
    --cc=davem@davemloft.net \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=maciej.fijalkowski@intel.com \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@redhat.com \
    --cc=sassmann@redhat.com \
    /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).