From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Lorenzo Bianconi <lorenzo@kernel.org>,
bpf@vger.kernel.org, netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, ast@kernel.org,
daniel@iogearbox.net, brouer@redhat.com, pabeni@redhat.com,
echaudro@redhat.com, lorenzo.bianconi@redhat.com,
toshiaki.makita1@gmail.com, andrii@kernel.org
Subject: Re: [PATCH v4 bpf-next 3/3] veth: allow jumbo frames in xdp mode
Date: Thu, 10 Mar 2022 12:30:44 +0100 [thread overview]
Message-ID: <87bkyeujrv.fsf@toke.dk> (raw)
In-Reply-To: <930b1ad3d84f7ca5a41ba75571f9146a932c5394.1646755129.git.lorenzo@kernel.org>
Lorenzo Bianconi <lorenzo@kernel.org> writes:
> Allow increasing the MTU over page boundaries on veth devices
> if the attached xdp program declares to support xdp fragments.
> Enable NETIF_F_ALL_TSO when the device is running in xdp mode.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/veth.c | 28 +++++++++++++++++-----------
> 1 file changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 47b21b1d2fd9..c5a2dc2b2e4b 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -293,8 +293,7 @@ static int veth_forward_skb(struct net_device *dev, struct sk_buff *skb,
> /* return true if the specified skb has chances of GRO aggregation
> * Don't strive for accuracy, but try to avoid GRO overhead in the most
> * common scenarios.
> - * When XDP is enabled, all traffic is considered eligible, as the xmit
> - * device has TSO off.
> + * When XDP is enabled, all traffic is considered eligible.
> * When TSO is enabled on the xmit device, we are likely interested only
> * in UDP aggregation, explicitly check for that if the skb is suspected
> * - the sock_wfree destructor is used by UDP, ICMP and XDP sockets -
> @@ -302,11 +301,13 @@ static int veth_forward_skb(struct net_device *dev, struct sk_buff *skb,
> */
> static bool veth_skb_is_eligible_for_gro(const struct net_device *dev,
> const struct net_device *rcv,
> + const struct veth_rq *rq,
> const struct sk_buff *skb)
> {
> - return !(dev->features & NETIF_F_ALL_TSO) ||
> - (skb->destructor == sock_wfree &&
> - rcv->features & (NETIF_F_GRO_FRAGLIST | NETIF_F_GRO_UDP_FWD));
> + return rcu_access_pointer(rq->xdp_prog) ||
> + !(dev->features & NETIF_F_ALL_TSO) ||
> + (skb->destructor == sock_wfree &&
> + rcv->features & (NETIF_F_GRO_FRAGLIST | NETIF_F_GRO_UDP_FWD));
> }
>
> static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
> @@ -335,7 +336,7 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
> * Don't bother with napi/GRO if the skb can't be aggregated
> */
> use_napi = rcu_access_pointer(rq->napi) &&
> - veth_skb_is_eligible_for_gro(dev, rcv, skb);
> + veth_skb_is_eligible_for_gro(dev, rcv, rq, skb);
> }
>
> skb_tx_timestamp(skb);
> @@ -1525,9 +1526,14 @@ static int veth_xdp_set(struct net_device *dev, struct bpf_prog *prog,
> goto err;
> }
>
> - max_mtu = PAGE_SIZE - VETH_XDP_HEADROOM -
> - peer->hard_header_len -
> - SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> + max_mtu = SKB_WITH_OVERHEAD(PAGE_SIZE - VETH_XDP_HEADROOM) -
> + peer->hard_header_len;
Why are we no longer accounting the size of the skb_shared_info if the
program doesn't support frags?
> + /* Allow increasing the max_mtu if the program supports
> + * XDP fragments.
> + */
> + if (prog->aux->xdp_has_frags)
> + max_mtu += PAGE_SIZE * MAX_SKB_FRAGS;
> +
> if (peer->mtu > max_mtu) {
> NL_SET_ERR_MSG_MOD(extack, "Peer MTU is too large to set XDP");
> err = -ERANGE;
> @@ -1549,7 +1555,7 @@ static int veth_xdp_set(struct net_device *dev, struct bpf_prog *prog,
> }
>
> if (!old_prog) {
> - peer->hw_features &= ~NETIF_F_GSO_SOFTWARE;
> + peer->hw_features &= ~NETIF_F_GSO_FRAGLIST;
The patch description says we're enabling TSO, but this change enables a
couple of other flags as well. Also, it's not quite obvious to me why
your change makes this possible? Is it because we can now execute XDP on
a full TSO packet at once? Because then this should be coupled to the
xdp_has_frags flag of the XDP program? Or will the TSO packet be
segmented before it hits the XDP program? But then this change has
nothing to do with the rest of your series?
Please also add this explanation to the commit message :)
-Toke
next prev parent reply other threads:[~2022-03-10 11:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-08 16:05 [PATCH v4 bpf-next 0/3] introduce xdp frags support to veth driver Lorenzo Bianconi
2022-03-08 16:05 ` [PATCH v4 bpf-next 1/3] net: veth: account total xdp_frame len running ndo_xdp_xmit Lorenzo Bianconi
2022-03-10 11:10 ` Toke Høiland-Jørgensen
2022-03-15 5:32 ` John Fastabend
2022-03-08 16:05 ` [PATCH v4 bpf-next 2/3] veth: rework veth_xdp_rcv_skb in order to accept non-linear skb Lorenzo Bianconi
2022-03-10 11:21 ` Toke Høiland-Jørgensen
2022-03-10 11:43 ` Lorenzo Bianconi
2022-03-10 19:06 ` Toke Høiland-Jørgensen
2022-03-10 19:26 ` Lorenzo Bianconi
2022-03-10 23:46 ` Lorenzo Bianconi
2022-03-12 21:18 ` Jakub Kicinski
2022-03-08 16:06 ` [PATCH v4 bpf-next 3/3] veth: allow jumbo frames in xdp mode Lorenzo Bianconi
2022-03-10 11:30 ` Toke Høiland-Jørgensen [this message]
2022-03-10 15:06 ` Lorenzo Bianconi
2022-03-10 18:53 ` Toke Høiland-Jørgensen
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=87bkyeujrv.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=echaudro@redhat.com \
--cc=kuba@kernel.org \
--cc=lorenzo.bianconi@redhat.com \
--cc=lorenzo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=toshiaki.makita1@gmail.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).