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 7342DA0554; Sat, 4 Jun 2022 13:36:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 126254021E; Sat, 4 Jun 2022 13:36:25 +0200 (CEST) Received: from forward501j.mail.yandex.net (forward501j.mail.yandex.net [5.45.198.251]) by mails.dpdk.org (Postfix) with ESMTP id 3E60F40041 for ; Sat, 4 Jun 2022 13:36:24 +0200 (CEST) Received: from sas2-599c596a5fe6.qloud-c.yandex.net (sas2-599c596a5fe6.qloud-c.yandex.net [IPv6:2a02:6b8:c08:b999:0:640:599c:596a]) by forward501j.mail.yandex.net (Yandex) with ESMTP id A16196234A5; Sat, 4 Jun 2022 14:36:23 +0300 (MSK) Received: from sas1-71299a9d5a62.qloud-c.yandex.net (sas1-71299a9d5a62.qloud-c.yandex.net [2a02:6b8:c08:210e:0:640:7129:9a9d]) by sas2-599c596a5fe6.qloud-c.yandex.net (mxback/Yandex) with ESMTP id CijiWPChSX-aNhKwkrB; Sat, 04 Jun 2022 14:36:23 +0300 X-Yandex-Fwd: 2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1654342583; bh=gg8UP9jaes5EBYPyXTFQ0VfFs5DThKU2eadMTwmzWc8=; h=In-Reply-To:From:Subject:Cc:References:Date:Message-ID:To; b=QkfmcE263jlPsSj6lLh/0nNZ8D+pnISgTDdko2b2U7fJGJdj96/z7QXwG0q8wJLEd +AYLp+gsTZCb7c6pQlFMsrA41WLVueC1fUPO3jGb0/FbvuqrfgwhqAf1kZzIVQ0EV+ U2s9QYq0DmozVghEhqfWQa2pWpdcbYm0bcY7PLmU= Authentication-Results: sas2-599c596a5fe6.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by sas1-71299a9d5a62.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 3y7a5suE9S-aMM8xI0T; Sat, 04 Jun 2022 14:36:22 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Message-ID: <218c355c-9bb9-0f7d-3f3f-f1f24f0fc782@yandex.ru> Date: Sat, 4 Jun 2022 12:36:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH] ip_frag: add IPv4 fast fragment switch and test data Content-Language: en-US To: Huichao Cai Cc: dev@dpdk.org, konstantin.ananyev@intel.com References: <1654161183-5391-1-git-send-email-chcchc88@163.com> <6ac80b09.42b.1812c82cc0e.Coremail.chcchc88@163.com> From: Konstantin Ananyev In-Reply-To: <6ac80b09.42b.1812c82cc0e.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 04/06/2022 03:19, Huichao Cai пишет: > I've seen some applications that have to rewrite fragment > functions themselves in order to use MBUF_FAST_FREE > features, such as iQiYi's DPVS. > > I am not sure that it will really help to improve performance, as if you have a lot of packets to fragment, you'll probably spend more time copying them. Might be it will help somehow if you'll have very rare occurrence of such packets. Also please keep in mind, that ip_frag is not the only one that does use indirect mbufs and refcnt. As another example - GSO implementation. So application writer has to be extremely careful when enabling MBUF_FAST_FREE. My personal advice - just don't use it, though I am quite conservative here. Anyway, as I said before, if there is a real use-case for it - I am ok to introduce new function that would do copying while fragmenting. Konstantin