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 D4EE2A0093; Thu, 23 Jun 2022 16:24:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 813A64067B; Thu, 23 Jun 2022 16:24:16 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 1667D40146 for ; Thu, 23 Jun 2022 16:24:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655994254; 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=O2S2mO4oK59EbfkXT5mbphqALFXVVAXKf7q9Jx8Tihw=; b=VSfUg/19+cVT/IL9+keYMv6+Yr+cYuWcqQD8WMwjb/3b3DE9iSSQ4Wkd59oNl24/Peyrsm CE9xOLlHd34cQC4TdUXnj9V236SbSjJG9jZZ+/FtupJq1ITsguGXIjMyrTh4luGdG9sM2c 8Ih8llIhcqDREetaVkhaPwsiLcDZSoM= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-299-n74Su5PdOeKMIFQi3jaNXQ-1; Thu, 23 Jun 2022 10:24:13 -0400 X-MC-Unique: n74Su5PdOeKMIFQi3jaNXQ-1 Received: by mail-lj1-f197.google.com with SMTP id c12-20020a2ebf0c000000b00258e5e6e125so3124135ljr.17 for ; Thu, 23 Jun 2022 07:24:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O2S2mO4oK59EbfkXT5mbphqALFXVVAXKf7q9Jx8Tihw=; b=sYDtdp7xZbM2iXewvo/M2T5EhvxezFLxFcxy+RR/rhsYVhG7eguK2PomC9WXleelca psCeKskyiAE1qpUtfZgeIPDYiv2gfKVdrrx8FzooHxkJ2NN/2xdijyRj5AZL/URoNl5p TiWHA4Bi3qEeZ3L/4Gwp1+vsPizStkW/lh9ct1fqEc4SLyJhd/SsWBAiwwdCNiyRa+W5 cFk1DqE6wxPg/or9bp5HlmNewaOURajI99esbhdocyiFvXCQgDjyI/y+Dvh8C481dywK beH+SOmLPxrakvLR59vxxQIc1VA8WO6rCWjrAMP/xRNUMHtGqRtNATJicyp3LulF/5v+ CpqQ== X-Gm-Message-State: AJIora/EGOIGYTahNBZ2ueEn7QQsZRYzXMhfHsetvgBZH+zplAxz8JJU vXgjO6dy7Ny4R1Kq8E+Rkxl86wtUA05nj0fc0OJji026dytqJLV3GaksfW2hZAHrfFNBXY6fYU5 fu20/WS2WMo6MHLe19xc= X-Received: by 2002:a05:6512:304d:b0:47f:79a8:294b with SMTP id b13-20020a056512304d00b0047f79a8294bmr5826778lfb.484.1655994251844; Thu, 23 Jun 2022 07:24:11 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sbqNRF240GZnIq875JskP0yfvGRX/2V+U7e2MFQ0ZzuF7J8Tjyh7owQsJOVhpJfYgzOnn1kUUkpXD+XyZYF34= X-Received: by 2002:a05:6512:304d:b0:47f:79a8:294b with SMTP id b13-20020a056512304d00b0047f79a8294bmr5826760lfb.484.1655994251649; Thu, 23 Jun 2022 07:24:11 -0700 (PDT) MIME-Version: 1.0 References: <1655561380-64616-1-git-send-email-chcchc88@163.com> <20220622193520.16e7c2e5@hermes.local> In-Reply-To: <20220622193520.16e7c2e5@hermes.local> From: David Marchand Date: Thu, 23 Jun 2022 16:24:00 +0200 Message-ID: Subject: Re: [PATCH] ip_frag: replace the rte memcpy with memcpy To: Stephen Hemminger , Konstantin Ananyev Cc: Huichao Cai , dev , "Ananyev, Konstantin" Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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 Thu, Jun 23, 2022 at 4:35 AM Stephen Hemminger wrote: > On Wed, 22 Jun 2022 23:49:39 +0100 > Konstantin Ananyev wrote: > > > > @@ -26,7 +25,7 @@ static inline void __fill_ipv4hdr_frag(struct rte_ipv4_hdr *dst, > > > const struct rte_ipv4_hdr *src, uint16_t header_len, > > > uint16_t len, uint16_t fofs, uint16_t dofs, uint32_t mf) > > > { > > > - rte_memcpy(dst, src, header_len); > > > + memcpy(dst, src, header_len); > > > > > > I am fine with replacements in test and inside the lib, for cases > > where 'len' parameter is constant value. > > Though as I said before, here 'header_len' is not a constant value. > > Are you sure it will not introduce any performance regression? > > Do you have any performance tests. The ip header options are very small. We have no alternative to this patch for fixing build with gcc 12 (which we want for rc2). As I mentionned during the maintainers call, I will be merging this patch for rc2 and wait for non regression tests. We can still revert this patch if the performance is impacted and go with an alternative approach. -- David Marchand