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 D49E2A00C5; Tue, 19 Jul 2022 10:19:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9A9C740698; Tue, 19 Jul 2022 10:19:07 +0200 (CEST) Received: from forward500j.mail.yandex.net (forward500j.mail.yandex.net [5.45.198.250]) by mails.dpdk.org (Postfix) with ESMTP id 9406C400D4 for ; Tue, 19 Jul 2022 10:19:06 +0200 (CEST) Received: from myt5-89cdf5c4a3a5.qloud-c.yandex.net (myt5-89cdf5c4a3a5.qloud-c.yandex.net [IPv6:2a02:6b8:c12:289b:0:640:89cd:f5c4]) by forward500j.mail.yandex.net (Yandex) with ESMTP id CE06C6CB6F40; Tue, 19 Jul 2022 11:19:05 +0300 (MSK) Received: by myt5-89cdf5c4a3a5.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id wCF5qxPfna-J4iKDcAZ; Tue, 19 Jul 2022 08:19:05 +0000 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1658218745; bh=cpCSlE7IkfemXqiwnn4dJApb2U32EBoJUiSNTYF27KI=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=glFBEa2R0GVilgc1lok3iSm08qGe3dEhuV41ptBSlMv20jmeBxXS69n4lJxM5p1Gc yZ7BA96iUB9XxQwD1HlP4C/466vTlitERioRjAivwFrs8SwF4SgxC9n1rYwFxk+rit aTv6CZAIYYGtrwvB66RiVeSMsQTyaORH92nVTdxc= Authentication-Results: myt5-89cdf5c4a3a5.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <049bf56b-152d-00b4-befb-506ba610f39e@yandex.ru> Date: Tue, 19 Jul 2022 09:19:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v2] ip_frag: add IPv4 fragment copy packet API Content-Language: en-US To: Huichao Cai Cc: dev@dpdk.org References: <1654784398-11315-1-git-send-email-chcchc88@163.com> <382d9871.2d7c.18200e4265e.Coremail.chcchc88@163.com> From: Konstantin Ananyev In-Reply-To: <382d9871.2d7c.18200e4265e.Coremail.chcchc88@163.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 Hi Huichao, > >     I've been busy lately, sorry to reply to you late. No worries at all. > >> Instead of implicitly assuming that output mbufs will be allocated > >> from pkt_in pool, it would be better to have output_pool as explicit >> parameter for that function. >> In a same way we have it for rte_ipv4_fragment_packet(). > >> If I understand correctly, here you assume that out_pkt will always >> be big enough to hold entire fragment, right? >> But that can not always be the case and probably we shouldn't assume >> that for generic function. >> I suppose safest way would be either use rte_pktmbuf_copy() here >> directly or do something similar to what that function doing ourselves here. > > reply: Thanks for the reminder, I will use explicit parameters and rte_pktmbuf_copy(); >> Forgot to mention, new API has to be experimental. > > reply: Does this mean adding _rte_experimental when declaring a function? > Yes, I meant _rte_experimental tag. Thanks Konstantin