From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7016E3233 for ; Mon, 26 Jun 2023 12:14:28 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB19B1728 for ; Mon, 26 Jun 2023 05:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687781651; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ajOPY7c86y/Eh/LHWm7DnjKqNr11/GAZcqbHvaOpUWU=; b=Qtc9pvnepLJ6SltFUZh9/DIaYZl4k6K1MQTrGwVTvtVfx06R05S0u4BQurCIyfeyxAOkLl OY1zcdYA5yCI4f37yA2jTiQcq06d3fgnYpgPax7yYZDCIva36bstA3RMGwNyYVngcyAIB4 q+DDyOQ2TmzyQ8BcVYlVtP8E1UpH1+4= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-17-n16kxn6rNYWDcI1seUZULQ-1; Mon, 26 Jun 2023 08:14:10 -0400 X-MC-Unique: n16kxn6rNYWDcI1seUZULQ-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-3111e2620ebso1751413f8f.3 for ; Mon, 26 Jun 2023 05:14:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687781649; x=1690373649; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ajOPY7c86y/Eh/LHWm7DnjKqNr11/GAZcqbHvaOpUWU=; b=cVZDYSfNacNm8tETjekCx5oWtqy9X5dI6P4ruJaklSnTe8v5gd5j6r+YuIcYSm47Rd wtklZ9vXVuk8wvVnVesWOcP6YA0Vtc0EMHSGGjJdCPBjzqMyWb+TRPcmnT7dJlMyDVBp CU70Kv5gTXN+rvOOtyYl6jaLSXg3nFrepkl0cSMIMkskx9FbsLOVAks9w6x1eu9tSW3W t5ZbIBG1j7+G+ddar9NPlTzyHvMSl0rTTJooSl6H+6hWSHjm7D8wFDB6LrwcrAcq17u3 c5v1zDcbHSn9WFoCTtPW/yKnLgjMgjydFQMZ5GElkDa0sop6eVbPH8y7+69VNrRu3MNm VhFQ== X-Gm-Message-State: AC+VfDw4ElhRuQIyTDSIxYnyXnHPn5mvv2EY8fFnwKouysVwm28C1/Hn bSYxgU8uwFgPyRoQiXs2zWGa7+wPD7PG6lCwyzghZWcMQpS13ygX0JFnIr0Dxxpty2cVyFLIqY8 ESkLo2TqHsWEEWngJKhLE9jCC X-Received: by 2002:a5d:6a0d:0:b0:313:e96e:98f7 with SMTP id m13-20020a5d6a0d000000b00313e96e98f7mr4026225wru.9.1687781648880; Mon, 26 Jun 2023 05:14:08 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ715wtiPIiCl3UkzhJBR8EpiHDoC12LKjv4MwwBQrUKa6bdkEf41dBbiYIXdRlMOelGwS70hA== X-Received: by 2002:a5d:6a0d:0:b0:313:e96e:98f7 with SMTP id m13-20020a5d6a0d000000b00313e96e98f7mr4026211wru.9.1687781648528; Mon, 26 Jun 2023 05:14:08 -0700 (PDT) Received: from redhat.com ([2.52.156.102]) by smtp.gmail.com with ESMTPSA id s2-20020adff802000000b00313de682eb3sm7186905wrp.65.2023.06.26.05.14.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jun 2023 05:14:08 -0700 (PDT) Date: Mon, 26 Jun 2023 08:14:04 -0400 From: "Michael S. Tsirkin" To: Heng Qi Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, Jason Wang , Xuan Zhuo , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend Subject: Re: [PATCH net-next v3 1/2] virtio-net: support coexistence of XDP and GUEST_CSUM Message-ID: <20230626080513-mutt-send-email-mst@kernel.org> References: <20230626120301.380-1-hengqi@linux.alibaba.com> <20230626120301.380-2-hengqi@linux.alibaba.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230626120301.380-2-hengqi@linux.alibaba.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On Mon, Jun 26, 2023 at 08:03:00PM +0800, Heng Qi wrote: > We are now re-probing the csum related fields and trying > to have XDP and RX hw checksum capabilities coexist on the > XDP path. For the benefit of: > 1. RX hw checksum capability can be used if XDP is loaded. > 2. Avoid packet loss when loading XDP in the vm-vm scenario. > > Signed-off-by: Heng Qi > Reviewed-by: Xuan Zhuo > --- > v2->v3: > - Use skb_checksum_setup() instead of virtnet_flow_dissect_udp_tcp(). > Essentially equivalent. > > drivers/net/virtio_net.c | 86 ++++++++++++++++++++++++++++++++++------ > 1 file changed, 73 insertions(+), 13 deletions(-) > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index 5a7f7a76b920..0a715e0fbc97 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -1568,6 +1568,44 @@ static void virtio_skb_set_hash(const struct virtio_net_hdr_v1_hash *hdr_hash, > skb_set_hash(skb, __le32_to_cpu(hdr_hash->hash_value), rss_hash_type); > } > > +static int virtnet_set_csum_after_xdp(struct virtnet_info *vi, > + struct sk_buff *skb, > + __u8 flags) > +{ > + int err = 0; > + > + /* When XDP program is loaded, for example, the vm-vm scenario > + * on the same host, packets marked as VIRTIO_NET_HDR_F_NEEDS_CSUM > + * will travel. Although these packets are safe from the point of > + * view of the vm, to avoid modification by XDP and successful > + * forwarding in the upper layer, why do you want tp avoid forwarding? did you mean "and to allow forwarding"? > we re-probe the necessary checksum > + * related information: skb->csum_{start, offset}, pseudo-header csum > + * using skb_chdcksum_setup(). typo > + * > + * This benefits us: Drop "This benefits us:" - benefits compared to what? > + * 1. XDP can be loaded when there's _F_GUEST_CSUM. > + * 2. The device verifies the checksum of packets, especially > + * benefiting for large packets. > + * 3. In the same-host vm-vm scenario, packets marked as > + * VIRTIO_NET_HDR_F_NEEDS_CSUM are no longer dropped after being > + * processed by XDP. please rewrite so the text makes sense in the final C file, not for someone reading the diff. In that cotext it does not matter that we used to drop packets or that we used to disable _F_GUEST_CSUM unless you explain why they had to be dropped previously. > + */ > + if (flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) { > + /* We don't parse SCTP because virtio-net currently doesn't > + * support CRC checksum offloading for SCTP. what does this refer to? where does it exclude SCTP? > + */ > + err = skb_checksum_setup(skb, true); > + } else if (flags & VIRTIO_NET_HDR_F_DATA_VALID) { > + /* We want to benefit from this: XDP guarantees that packets marked > + * as VIRTIO_NET_HDR_F_DATA_VALID still have correct csum after they > + * are processed. drop "We want to benefit from this: " > + */ > + skb->ip_summed = CHECKSUM_UNNECESSARY; > + } > + > + return err; > +} > + > static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq, > void *buf, unsigned int len, void **ctx, > unsigned int *xdp_xmit, > @@ -1576,6 +1614,7 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq, > struct net_device *dev = vi->dev; > struct sk_buff *skb; > struct virtio_net_hdr_mrg_rxbuf *hdr; > + __u8 flags; > > if (unlikely(len < vi->hdr_len + ETH_HLEN)) { > pr_debug("%s: short packet %i\n", dev->name, len); > @@ -1584,6 +1623,13 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq, > return; > } > > + /* Save the flags of the hdr before XDP processes the data. > + * It is ok to use this for both mergeable and small modes. > + * Because that's what we do now. What does the last sentence mean? Instead please explain why this is necessary. what can change the header? > + */ > + if (unlikely(vi->xdp_enabled)) > + flags = ((struct virtio_net_hdr_mrg_rxbuf *)buf)->hdr.flags; > + > if (vi->mergeable_rx_bufs) > skb = receive_mergeable(dev, vi, rq, buf, ctx, len, xdp_xmit, > stats); > @@ -1595,23 +1641,37 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq, > if (unlikely(!skb)) > return; > > - hdr = skb_vnet_hdr(skb); > - if (dev->features & NETIF_F_RXHASH && vi->has_rss_hash_report) > - virtio_skb_set_hash((const struct virtio_net_hdr_v1_hash *)hdr, skb); > - > - if (hdr->hdr.flags & VIRTIO_NET_HDR_F_DATA_VALID) > - skb->ip_summed = CHECKSUM_UNNECESSARY; > + if (unlikely(vi->xdp_enabled)) { > + /* Required to do this before re-probing and calculating > + * the pseudo-header checksum. What if checksum was disabled on device? No need for all the elaborate hacks then, right? What about disabling by ethtool? > + */ > + skb->protocol = eth_type_trans(skb, dev); > + skb_reset_network_header(skb); > + if (virtnet_set_csum_after_xdp(vi, skb, flags) < 0) { > + pr_debug("%s: errors occurred in setting partial csum", > + dev->name); > + goto frame_err; > + } > + } else { > + hdr = skb_vnet_hdr(skb); > + if (dev->features & NETIF_F_RXHASH && vi->has_rss_hash_report) > + virtio_skb_set_hash((const struct virtio_net_hdr_v1_hash *)hdr, skb); > + > + if (hdr->hdr.flags & VIRTIO_NET_HDR_F_DATA_VALID) > + skb->ip_summed = CHECKSUM_UNNECESSARY; > + > + if (virtio_net_hdr_to_skb(skb, &hdr->hdr, > + virtio_is_little_endian(vi->vdev))) { > + net_warn_ratelimited("%s: bad gso: type: %u, size: %u\n", > + dev->name, hdr->hdr.gso_type, > + hdr->hdr.gso_size); > + goto frame_err; > + } > > - if (virtio_net_hdr_to_skb(skb, &hdr->hdr, > - virtio_is_little_endian(vi->vdev))) { > - net_warn_ratelimited("%s: bad gso: type: %u, size: %u\n", > - dev->name, hdr->hdr.gso_type, > - hdr->hdr.gso_size); > - goto frame_err; > + skb->protocol = eth_type_trans(skb, dev); > } > > skb_record_rx_queue(skb, vq2rxq(rq->vq)); > - skb->protocol = eth_type_trans(skb, dev); > pr_debug("Receiving skb proto 0x%04x len %i type %i\n", > ntohs(skb->protocol), skb->len, skb->pkt_type); > > -- > 2.19.1.6.gb485710b