From: Duyck, Alexander H <alexander.h.duyck@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH v6 1/2] i40e: add XDP support for pass and drop actions
Date: Tue, 23 May 2017 20:00:29 +0000 [thread overview]
Message-ID: <1495569627.2562.18.camel@intel.com> (raw)
In-Reply-To: <CAJ+HfNhx1gPJ1FsDKXczPXWmVyao4mNJGwrOD4h9UrhoUkOTKg@mail.gmail.com>
On Tue, 2017-05-23 at 20:51 +0200, Bj?rn T?pel wrote:
> 2017-05-23 18:51 GMT+02:00 Alexander Duyck <alexander.duyck@gmail.com>:
> >
> > On Tue, May 23, 2017 at 12:33 AM, Bj?rn T?pel <bjorn.topel@gmail.com> wrote:
> > >
> > > From: Bj?rn T?pel <bjorn.topel@intel.com>
> > >
> > > This commit adds basic XDP support for i40e derived NICs. All XDP
> > > actions will end up in XDP_DROP.
> > >
> > > Signed-off-by: Bj?rn T?pel <bjorn.topel@intel.com>
> >
> > So I only really see one issue which I pointed out earlier. Basically
> > the i40e_change_mtu call can't really be dependent on vsi->rx_buf_len
> > since rx_buf_len is changed as a result of changing the MTU.
> >
> > >
> > > ---
> > > drivers/net/ethernet/intel/i40e/i40e.h | 7 ++
> > > drivers/net/ethernet/intel/i40e/i40e_main.c | 75 ++++++++++++++++
> > > drivers/net/ethernet/intel/i40e/i40e_txrx.c | 130 +++++++++++++++++++++-------
> > > drivers/net/ethernet/intel/i40e/i40e_txrx.h | 1 +
> > > 4 files changed, 182 insertions(+), 31 deletions(-)
> > >
> >
> > [...]
> >
> > >
> > > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > > index 8d1d3b859af7..c8b1db0ebb9e 100644
> > > --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> > > +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > > @@ -27,6 +27,7 @@
> > > #include <linux/etherdevice.h>
> > > #include <linux/of_net.h>
> > > #include <linux/pci.h>
> > > +#include <linux/bpf.h>
> > >
> > > /* Local includes */
> > > #include "i40e.h"
> > > @@ -2408,6 +2409,13 @@ static int i40e_change_mtu(struct net_device *netdev, int new_mtu)
> > > struct i40e_vsi *vsi = np->vsi;
> > > struct i40e_pf *pf = vsi->back;
> > >
> > > + if (i40e_enabled_xdp_vsi(vsi)) {
> > > + int frame_size = new_mtu + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN;
> > > +
> > > + if (frame_size > vsi->rx_buf_len)
> > > + return -EINVAL;
> > > + }
> > > +
> >
> > So this code suffers from the same issue that John's ixgbe code did.
> > You might be better off implementing something like we did with
> > i40e_vsi_configure_rx. Basically the upper limit can be either 3K or
> > 2K if the page size greater than 4K or the LEGACY_RX flag is set. You
> > might look at adding a check here for that instead of just comparing
> > it to vsi->rx_buf_len since rx_buf_len can change depending on the MTU
> > size.
> >
>
> You pointed this out in our private conversation, but obviously I
> didn't get it... :-(
>
> So, something in lines of:
>
> @@ -2396,6 +2397,18 @@ static void i40e_sync_filters_subtask(struct i40e_pf *pf)
> }
>
> /**
> + * i40e_max_xdp_frame_size - returns the maximum allowed frame size for XDP
> + * @vsi: the vsi
> + **/
> +static int i40e_max_xdp_frame_size(struct i40e_vsi *vsi)
> +{
> + if (PAGE_SIZE >= 8192 || (vsi->back->flags & I40E_FLAG_LEGACY_RX))
> + return I40E_RXBUFFER_2048;
> + else
> + return I40E_RXBUFFER_3072;
> +}
> +
> +/**
> * i40e_change_mtu - NDO callback to change the Maximum Transfer Unit
> * @netdev: network interface device structure
> * @new_mtu: new value for maximum frame size
> @@ -2408,6 +2421,13 @@ static int i40e_change_mtu(struct net_device
> *netdev, int new_mtu)
> struct i40e_vsi *vsi = np->vsi;
> struct i40e_pf *pf = vsi->back;
>
> + if (i40e_enabled_xdp_vsi(vsi)) {
> + int frame_size = new_mtu + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN;
> +
> + if (frame_size > i40e_max_xdp_frame_size(vsi))
> + return -EINVAL;
> + }
> +
> netdev_info(netdev, "changing MTU from %d to %d\n",
> netdev->mtu, new_mtu);
> netdev->mtu = new_mtu;
>
>
>
> Bj?rn
Yes this is exactly what I had in mind. If you can fold this into your
patch then I would say we pretty much have this all wrapped up (at
least until we find something in testing :-)).
Thanks.
- Alex
next prev parent reply other threads:[~2017-05-23 20:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-23 7:33 [Intel-wired-lan] [PATCH v6 0/2] i40e: support for XDP =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2017-05-23 7:33 ` [Intel-wired-lan] [PATCH v6 1/2] i40e: add XDP support for pass and drop actions =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2017-05-23 16:51 ` Alexander Duyck
2017-05-23 18:51 ` =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2017-05-23 20:00 ` Duyck, Alexander H [this message]
2017-05-23 20:33 ` =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2017-05-23 7:33 ` [Intel-wired-lan] [PATCH v6 2/2] i40e: add support for XDP_TX action =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
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=1495569627.2562.18.camel@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=intel-wired-lan@osuosl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.