From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8CDCFA0547; Fri, 17 Jun 2022 18:31:20 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 41BE3427F3; Fri, 17 Jun 2022 18:31:20 +0200 (CEST) Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by mails.dpdk.org (Postfix) with ESMTP id 9501440F19 for ; Fri, 17 Jun 2022 18:31:18 +0200 (CEST) Received: by mail-pf1-f176.google.com with SMTP id bo5so4599516pfb.4 for ; Fri, 17 Jun 2022 09:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=dDWwFkGQg6tF1dpuuIS9kfnDWYNmnOLdtycg8cW+GBo=; b=lsJUJXja0VqXgjQszWQ7E2iQGEeB6EfIUg8NNqRzea6675D/4E4m/Q0n9oQdJwVJv4 2Cry89XzeOMiC2Pg8j0uM7KunRhA6Bs7zQQZQXptSb0IPd4VvuUIpj3ZAoJe1Ix3nb8J 0SIKOuzEaydOoUXxq5vEF46O93LRwwuFAlIy9Pgk/TmT5KRg7TbF6rP5za38yIJcitJ+ uOirOpG70j+MlmZrpd96ZQ2scPQfk4W32e+Qk4v+HUXqOLE1jXOEhefXnessS874KdUX srMyyyFYmTMjpRbf06GKEn4TKzA8wB1ILIbOqqopb/OLqTVeIuxppb/BWMLNUqR4Tuhb xPLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=dDWwFkGQg6tF1dpuuIS9kfnDWYNmnOLdtycg8cW+GBo=; b=a2666oIXuVcLeSS9LR3BzcnRbPEZmWZUia1ZkxgPUJoDDBXYDFiWZf2eSRxcbEEE// cO7Cz80p6d878J6i1rHkr6L5uKs0ISkcR5uW369vRlr3j2NbuTrzFdZs7WSTWEqVr828 gBQcj+sAB/pttRhWsuMi2WoyejlaVAQfKzdkHKmNdc411FfsLZWHfWy3AFaBwr6aY1nU afHaKfDw1AUOIqtEdDppRQOooqH0ujC5HWDx+EvdY6yJtX/ueJHY0TTwOO8DTJDk4oey 92dvbXIHf8muSEsM3OGH4ElWFAPypiQ9v2b/TEItFOLKafDtTef2qO/BuTzCbKjz4b0F w99g== X-Gm-Message-State: AJIora/fHl0GseURAY2RMMyW1BN2+OSn/4RVpxbRgJzGlBD7BLALa434 /CflYcIq37/jsOVkwrB3y6Zkww== X-Google-Smtp-Source: AGRyM1sfLN9haczlpZb6qdxEMvex97mC+8gTvjCIAa6uJ6v0rkuIhwsBp6wgyxa9H+nmGeUKaoJpLg== X-Received: by 2002:aa7:9e41:0:b0:524:dd4f:a133 with SMTP id z1-20020aa79e41000000b00524dd4fa133mr4312886pfq.21.1655483477629; Fri, 17 Jun 2022 09:31:17 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id f5-20020aa79685000000b0050dc7628196sm3891207pfk.112.2022.06.17.09.31.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jun 2022 09:31:17 -0700 (PDT) Date: Fri, 17 Jun 2022 09:31:12 -0700 From: Stephen Hemminger To: "Huichao Cai" Cc: "David Marchand" , "Konstantin Ananyev" , dev , "Thomas Monjalon" Subject: Re: [PATCH v7] ip_frag: add IPv4 options fragment and test data Message-ID: <20220617093112.6c7f4945@hermes.local> In-Reply-To: <7d176bd8.1b9e.1816fca693b.Coremail.chcchc88@163.com> References: <1649649325-1942-1-git-send-email-chcchc88@163.com> <1649993210-1854-1-git-send-email-chcchc88@163.com> <20220616093111.763435f4@hermes.local> <7d176bd8.1b9e.1816fca693b.Coremail.chcchc88@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, 17 Jun 2022 11:52:25 +0800 (CST) "Huichao Cai" wrote: > Hi,Stephen >=20 >=20 > There are some things I don't quite understand.Hope you can answer that. > This will help me avoid similar errors in subsequent patch submissions.Th= anks! >=20 >=20 > There are places where rte_memcpy functions are used=EF=BC=9A > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > In test_ipfrag.c=EF=BC=9A > from func test_get_ipv4_opt:=20 > rte_memcpy(expected_opt->data,expected_first_frag_ipv4_opts_copied,sizeof= (expected_first_frag_ipv4_opts_copied)); > rte_memcpy(expected_opt>data,expected_first_frag_ipv4_opts_nocopied,sizeo= f(expected_first_frag_ipv4_opts_nocopied)); =20 > rte_memcpy(expected_opt->data,expected_sub_frag_ipv4_opts_copied,sizeof(e= xpected_sub_frag_ipv4_opts_copied)); > rte_memcpy(expected_opt->data,expected_sub_frag_ipv4_opts_nocopied,sizeof= (expected_sub_frag_ipv4_opts_nocopied)); > from func v4_allocate_packet_of: > rte_memcpy(hdr + 1, opt.data, opt.len); > from func test_get_frag_opt: > rte_memcpy(opt->data, iph_opt, opt_len); >=20 >=20 > In rte_ipv4_fragmentation.c: > from func v4_allocate_packet_of: > rte_memcpy(dst, src, header_len); > from func __create_ipopt_frag_hdr: >=20 > rte_memcpy(ipopt_frag_hdr, iph, sizeof(struct rte_ipv4_hdr)); > rte_memcpy(ipopt_frag_hdr + ipopt_len, p_opt, p_opt[1]); > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > These are the compilation errors: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > test_ipfrag.c:230 > In test_ipfrag.c=EF=BC=9A > from func v4_allocate_packet_of: > rte_memcpy(hdr + 1, opt.data, opt.len); > rte_ipv4_fragmentation.c:68 > In rte_ipv4_fragmentation.c: > from func __create_ipopt_frag_hdr: > rte_memcpy(ipopt_frag_hdr + ipopt_len, p_opt, p_opt[1]); > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > 1.Do I need to replace all rte_memcpy with memcpy or only the two rte_mem= cpy that compile the error are replaced by memcpy? I would just replace all of the rte_memcpy with memcpy > 2. > >Since the copies will all be short why bother using rte_memcpy() all over > >the place. Especially in the test code, just use memcpy(). =20 > For example,in app/test-pmd/cmdline.c:from func cmd_set_vxlan_parsed:rte_= memcpy(vxlan_encap_conf.vni, &id.vni[1], 3);Why this place can be used rte_= memcpy? > 3.For example, how such a compilation error occurs: > ../app/test/test_ipfrag.c:57:17: note: at offset [5, 40] into object=E2= =80=98data=E2=80=99 of size 40 > 4.Under what circumstances can we use rte_memcpy? It depends. The recommendation here was that fixing warnings is higher prio= rity that saving a few cycles in an underutilized part of DPDK. Rte_memcpy() was added in early versions of DPDK because the standard toolc= hain gcc/glibc was not using the optimum set of instructions on x86. Rather than fix glib= c, Intel wrote their own rte_memcpy(). Then DPDK developers, started to assume that rte_me= mcpy() is always best. I expect that rte_memcpy() is able to do better than memcpy() for larger co= pies because it is likely to use bigger vector instructions and check for alignment. For small copies just doing the mov's directly is going to be as fast or fa= ster. In fact, lots of places in DPDK should replace rte_memcpy() with simple structure assignment to preserve type safe= ty. This is somewhat historical data, it might be wrong. It would be worthwhile= to have benchmarks across different sizes (variable and fixed), different compilers, and diffe= rent CPU's. There might be surprising results.