From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5398B202C5C for ; Fri, 26 Dec 2025 07:37:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766734670; cv=none; b=oV+ObdckapD2YQIRA5RjF9cQnknlWAJb9v4tf7Qpi+G5e5vz2I9H4FqXtPZ8H4Sb6j8lXCbgexMOont+/Gt362n/eDPmX7VobyRu6PKlE/90lKJVjbKB1hq4Wkv3oYMtH9jINOLoTv2WYd9f09lMcAv19t1B0B7P6T2Fkl2j9qM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766734670; c=relaxed/simple; bh=0rmvrB0jFA9AqaRU7FDxlBBzIIKJKv2DCijQxPr9ssk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tgMRY631K5+8qpmqq8T+g8S1crog4Bs98n7DUIFYsT5NMjtMI9sky/wLkH8AESE9q3m0sh+EsbBxiBLf/qz2YrF6vnPtktO30FmysBlo1fhsVBI8pOTDBacEpM4fYWB6/Cdb3V1vaex15cCkIK/GNAA/VUbm8G7dSQ/GCaGPKIs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=CbB7AuTM; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=YnCgc+lX; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="CbB7AuTM"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="YnCgc+lX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1766734667; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CUh1KaOXjv2HvFwemQznNzF51XENR9Lh865zEQseUv4=; b=CbB7AuTMlsg6cj5qvAMo5StUAHfZuv2yHKqxN9BMgBT+AuMQXQacOBLSDVnH5vru9aycwg ULY6Uzxnr7Dp/yZu9XGqVe10kkUCz5haLZKoEakKxKYFd93POLROpB7VOUTKC+EDtghrTy 55smT0tfcwgoU2UDNqGWQmYoEUtL+aw= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-374-aoxbtqBIPQqpgv9SH8xTzQ-1; Fri, 26 Dec 2025 02:37:46 -0500 X-MC-Unique: aoxbtqBIPQqpgv9SH8xTzQ-1 X-Mimecast-MFC-AGG-ID: aoxbtqBIPQqpgv9SH8xTzQ_1766734665 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-477b8a667bcso96611095e9.2 for ; Thu, 25 Dec 2025 23:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1766734665; x=1767339465; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=CUh1KaOXjv2HvFwemQznNzF51XENR9Lh865zEQseUv4=; b=YnCgc+lXfH+0r+B2EAfv/hl36yrFbaf9AkldYe1iYNcfYhTD7DE3rYrMuZX5cUlNA0 BrzTZw1tQmo1vhUi1dd9UFoXDgthxNEctISCYnfkPaJlKGZC+7uZGQUZEVBdlLMw0uG1 6jZ5eezUCnu/CzCUZp7x6z8mHBUBz0qIsCQ5M3gJS8JBOh+Xb3xu/i4ZKR3gTGDNfAkl 6Tg4bRbNxxD/Bn6inHm4bUedwMaZMI+HqcDGcNOZXeBsog68aC6FrtZ9SxeAymX+VN3h yMXtFIFM/693GQ7J9Wczx/GPuZAUTHA0ji1INh7fTSFTHjtCf9pSuYtU8od+ftsGsn4m l31w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766734665; x=1767339465; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CUh1KaOXjv2HvFwemQznNzF51XENR9Lh865zEQseUv4=; b=Oyh/m+X+UfjQBZs2O3RwovKAMk76ti83gIGttQfvDQUbTD3jKsujDvNKVo6AxPc5iP d0Hf8SMFvMW515HuEM9A94PCrBy0PFNp1VlofRhnuXTvXUG0oEAiTQQri3URxSu2qCnf 7VmhlV+5rmkBFNT5sy8bOp/xRykD4MNRK53aOMKroQ052w5LLJDT1ZhdWW8Z7fwxZ6Dl px5iuyPK4lfj4lHxMbMtCUji7Lswsyhr/Lmm761NKpJicmJN+Wldwn1yqMZ8iy76zwfD 9Xh6bSin3mUoJQnUiIkas0MoJA8+SIGFea0Hy9ou8lwqLMeCdUhBwyIYFQiMjDc9ycO/ W0Dw== X-Forwarded-Encrypted: i=1; AJvYcCU1dhSePLphExZyp9itF+uphVMozJItGfM3WuHPLV+nEdk2O7Oc1dE10oObH+M5eLjn3Lts97Dzi/fcbeU=@vger.kernel.org X-Gm-Message-State: AOJu0Yy9fi5KuP2UqMJJ9a2L3sTLo4Jqic6nwoPDDHWB7mr8Jew5UMcj r5Lnqttth+BHWXPDbPggW9LK/23FGnQsxICyybrlPlrNDuDoTZJxQG3WCuPL0DQcE0+ESVw/5Aw p7j/fG+Z9co+OM8vMt0F+wRrLyKHXUDVTuPL+JD1frm2QCF8xaYQzpey5rMo/APoCoQ== X-Gm-Gg: AY/fxX7rQNi5SHK3djINvVFF8Jr5MCZq2o5+FCKqQ4lPzRhaOwqiAfWOBzAQbl4X6yn +jGmzQQw9vDLRPd9BH/5+/accb0ZAP9uUmvllxwnAbGsd0LBlN6UBriO8Z6Csw5K5QG02VFYzc3 CgVW4hwvR8RXLFf1X+dHDRNdIKo6GNJAl69UWTRM2rRfHMprtBUbECuFJtNi3D7EuwVTUPUnYjo y2+XFpgY0yp8mkOlYFZhWBy99PvypsaFu8uulEDKT9xLUpGDzGp0tPxoBJTcC1EiXavja2nbEkU HxGZ0XLZPEsZmb5hCPMZBX2oD2xaiRm06NJdgPDbv4f6ygbR6xhMuZ+vekkdTrKySpnnbebrgax J1Fck+VLscpMAKSUKGZvaxqnXw7W/FgUoLQ== X-Received: by 2002:a05:600c:8183:b0:477:fad:acd9 with SMTP id 5b1f17b1804b1-47d195a9834mr226258575e9.34.1766734664663; Thu, 25 Dec 2025 23:37:44 -0800 (PST) X-Google-Smtp-Source: AGHT+IHpsFWjeude7gy71vuh6vSWasoySUpj/LvWEgjphgTCKyVNexu8UQ8V6vCGw/Jfq9ZpZj/RgA== X-Received: by 2002:a05:600c:8183:b0:477:fad:acd9 with SMTP id 5b1f17b1804b1-47d195a9834mr226258395e9.34.1766734664223; Thu, 25 Dec 2025 23:37:44 -0800 (PST) Received: from redhat.com (IGLD-80-230-31-118.inter.net.il. [80.230.31.118]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d193522cdsm363228075e9.4.2025.12.25.23.37.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Dec 2025 23:37:43 -0800 (PST) Date: Fri, 26 Dec 2025 02:37:40 -0500 From: "Michael S. Tsirkin" To: Jason Wang Cc: Xuan Zhuo , netdev@vger.kernel.org, Eugenio =?iso-8859-1?Q?P=E9rez?= , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, Bui Quang Minh Subject: Re: [PATCH net 1/3] virtio-net: make refill work a per receive queue work Message-ID: <20251226022727-mutt-send-email-mst@kernel.org> References: <20251223152533.24364-1-minhquangbui99@gmail.com> <20251223152533.24364-2-minhquangbui99@gmail.com> <1766540234.3618076-1-xuanzhuo@linux.alibaba.com> <20251223204555-mutt-send-email-mst@kernel.org> <20251225112729-mutt-send-email-mst@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Dec 26, 2025 at 09:31:26AM +0800, Jason Wang wrote: > On Fri, Dec 26, 2025 at 12:27 AM Michael S. Tsirkin wrote: > > > > On Thu, Dec 25, 2025 at 03:33:29PM +0800, Jason Wang wrote: > > > On Wed, Dec 24, 2025 at 9:48 AM Michael S. Tsirkin wrote: > > > > > > > > On Wed, Dec 24, 2025 at 09:37:14AM +0800, Xuan Zhuo wrote: > > > > > > > > > > Hi Jason, > > > > > > > > > > I'm wondering why we even need this refill work. Why not simply let NAPI retry > > > > > the refill on its next run if the refill fails? That would seem much simpler. > > > > > This refill work complicates maintenance and often introduces a lot of > > > > > concurrency issues and races. > > > > > > > > > > Thanks. > > > > > > > > refill work can refill from GFP_KERNEL, napi only from ATOMIC. > > > > > > > > And if GFP_ATOMIC failed, aggressively retrying might not be a great idea. > > > > > > Btw, I see some drivers are doing things as Xuan said. E.g > > > mlx5e_napi_poll() did: > > > > > > busy |= INDIRECT_CALL_2(rq->post_wqes, > > > mlx5e_post_rx_mpwqes, > > > mlx5e_post_rx_wqes, > > > > > > ... > > > > > > if (busy) { > > > if (likely(mlx5e_channel_no_affinity_change(c))) { > > > work_done = budget; > > > goto out; > > > ... > > > > > > is busy a GFP_ATOMIC allocation failure? > > Yes, and I think the logic here is to fallback to ksoftirqd if the > allocation fails too much. > > Thanks True. I just don't know if this works better or worse than the current design, but it is certainly simpler and we never actually worried about the performance of the current one. So you know, let's roll with this approach. I do however ask that some testing is done on the patch forcing these OOM situations just to see if we are missing something obvious. the beauty is the patch can be very small: 1. patch 1 do not schedule refill ever, just retrigger napi 2. remove all the now dead code this way patch 1 will be small and backportable to stable. > > > > > > > > > > Not saying refill work is a great hack, but that is the reason for it. > > > > -- > > > > MST > > > > > > > > > > Thanks > >