Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1348555pxb; Tue, 17 Aug 2021 09:31:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw246i2uRiVUo5cCtNKNhdloAf8qavzOHunziGkk1w7igtpWAaBBItFLcDTMzt9VZ0QfFYc X-Received: by 2002:a05:6e02:c8b:: with SMTP id b11mr2930993ile.90.1629217917330; Tue, 17 Aug 2021 09:31:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629217917; cv=none; d=google.com; s=arc-20160816; b=Np2OZE5ELcBsgIDrKDapqLYe/LN/rtwz9JTieBqu+PWrDU8RpKee4x+me/QTpat9ZQ 91mcCsf5Gz8gd5RVGi7fKVOx6yt1NMOlRcPn7yZRwhpg/rzI1u/Vl9ZmBfMnS+uqUmeJ TKZ0onpbux4ieI/FslGLaR+qnzJUG92F48zAb3Xw5EWbgwViEmG8RDVOC7g3qBmxBCjp YEbQhhdyYHHBycu7AluJC8usdhblcQvhVn8bLPUAfD426zDtmCxFt1nsOIHRUxP+t9NF fFMgHgz4FiuRb2N0gxKZ66Dv/9QRDk63R1rn0IJgwE1jLfINuPt9XI527Ml6W26R1V+h RXpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=wQTsET6oBxsb+BxyZU/lAk0roJlCRzO1Zh+nAP6uf8g=; b=BhXHk8gMb3N4lswoyLAiKjkngzTePjtkiBpEDNeHDk8VO9wU6XnwcC83giIRHxcftY 9uRlqMwsNtezr6NEpB1bhhAR/TnKukxCuEQ1Kg7gn2fat1NjKKBS0bBxZePuKi5tK74f 3XH+akjOT1tzKQ1veloKSCeTfAJJ/q5fdm6MiuUUE4Gfz83xVYkvDiLN8cKE1uhzbcv9 DHt1Jbbr7xwr1PAaQZ+V6T7cKSI012RDGpzVlexpvFgRBXH6Y1l0WwhHxBVbgStz67dy FOs+RfIdrGUL7LcOmPOQUqKxnR2UgCrh1gwk+rTAItKbpQoKcCEDkouPapEumGczHDvP P0KQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=CZ6E06co; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id az34si2857279jab.63.2021.08.17.09.31.44; Tue, 17 Aug 2021 09:31:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=CZ6E06co; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230152AbhHQQ1M (ORCPT + 99 others); Tue, 17 Aug 2021 12:27:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54808 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229518AbhHQQ1F (ORCPT ); Tue, 17 Aug 2021 12:27:05 -0400 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69C16C061764; Tue, 17 Aug 2021 09:26:32 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id mq2-20020a17090b3802b0290178911d298bso7178483pjb.1; Tue, 17 Aug 2021 09:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=wQTsET6oBxsb+BxyZU/lAk0roJlCRzO1Zh+nAP6uf8g=; b=CZ6E06co9olcvRslsYUsuQlobgSqRLzP/3SE196pquYkfaBqNwCuoEgrIYHoss/0Gt 93Cw8HSzd4MYs+8jkl40GA1jrLW6aNRALZt6M67IOdbTXCVrFxiXnuxohpVU7NTwrHIE Hdu3hLIAsmagN139GDl0FNlaJXWpLOVmo1rPiebgzPVe23dmEUnupaoYmw5ZznSefyUW zQMoebijBOvtWMRO/ocml8bLSsmXLKK8TK6Bt660EyvFJUGx1Rx9KrnZ6cIFrLkLZfLI nuG+FkTwyl2oekOzyB1Dgoe2g1+VfbwOyWCk9bhA3MUr+/e/h9nSNsh+Fcm3MZjedDBv j71Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wQTsET6oBxsb+BxyZU/lAk0roJlCRzO1Zh+nAP6uf8g=; b=L6/sGvbSIHriR1KZTxJWl6c3CF2cDToSuO4XedI+e15I0cXqe937Lw8+Bj9l1F0u3h 3zeFJ0ohSJKEAVWMf16gBTZmYFkjDX3MWoZHYL+K/p2ODaSZHiMBQLrxmDmC7gzlA+9s bUYz7s7i9PGHcsRxgwUlmq9ZO5hsVg8U2bHJp/5WqdtfjIlpKvKddHlJ7ZiFPaCFFU4R cZiiVncJk1l+2Tn9UPrtbFHW2VffGeADtldhsmOLPr9gl7HfrV0BmsYoOqSQpP9oL58k 0TzoR+7eNvJSBCQbnVsL5Rl8tXa7h7r75gJ8fRyPu9fx9PRPQVMfBcSRAuDOe6LopQkm VVXA== X-Gm-Message-State: AOAM533pt/sQx2TYA+SoogZsKNAhXyA1hY9bKr+pTKH5np+BZKLM1mTT WGdLC5M6PDw99Ubcrd8ccyA= X-Received: by 2002:a62:3185:0:b0:3e1:ae2e:4b78 with SMTP id x127-20020a623185000000b003e1ae2e4b78mr4358532pfx.18.1629217591846; Tue, 17 Aug 2021 09:26:31 -0700 (PDT) Received: from gmail.com ([2601:600:8500:5f14:bd71:fea:c430:7b0a]) by smtp.gmail.com with ESMTPSA id r11sm2568361pjd.26.2021.08.17.09.26.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Aug 2021 09:26:31 -0700 (PDT) Date: Tue, 17 Aug 2021 09:22:20 -0700 From: "avagin@gmail.com" To: David Laight Cc: 'Bui Quang Minh' , Eric Dumazet , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , "davem@davemloft.net" , "kuba@kernel.org" , "yoshfuji@linux-ipv6.org" , "dsahern@kernel.org" , "willemb@google.com" , "pabeni@redhat.com" , "alexander@mihalicyn.com" , "lesedorucalin01@gmail.com" Subject: Re: [PATCH v2 1/2] udp: UDP socket send queue repair Message-ID: References: <20210811154557.6935-1-minhquangbui99@gmail.com> <721a2e32-c930-ad6b-5055-631b502ed11b@gmail.com> <7f3ecbaf-7759-88ae-53d3-2cc5b1623aff@gmail.com> <489f0200-b030-97de-cf3a-2d715b07dfa4@gmail.com> <3f861c1d-bd33-f074-8ef3-eede9bff73c1@gmail.com> <29dc7ac9781344f1a57e16c14900a7da@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <29dc7ac9781344f1a57e16c14900a7da@AcuMS.aculab.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 13, 2021 at 01:00:12PM +0000, David Laight wrote: > From: Bui Quang Minh > > Sent: 13 August 2021 12:08 > ... > > The reason we want to dump the packet in send queue is to make to state of the > > application consistent. The scenario is that when an application sends UDP > > packets via UDP_CORK socket or with MSG_MORE, CRIU comes and checkpoints the > > application. If we drop the data in send queue, when application restores, it > > sends some more data then turns off the cork and actually sends a packet. The > > receiving side may get that packet but it's unusual that the first part of that > > packet is missing because we drop it. So we try to solve this problem with some > > help from the Linux kernel. > > Patient: It hurts if I do xxx. > Doctor: Don't do xxx then. > > It has to be more efficient to buffer partial UDP packets > in userspace and only send when all the packet is available. You are right. It can be more efficient, but we don't have controls over user-space processes, and they can do whatever the kernel allows them to do. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales)