Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp152432pxb; Wed, 18 Nov 2020 00:26:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJylkDOqqTwXD6Bu/nOrzkDfDmF4FM/gK676RB67xI9qDC5aqOebXmCn/3Ru6FDTEjt2v3uV X-Received: by 2002:a17:906:c096:: with SMTP id f22mr22200839ejz.488.1605688012447; Wed, 18 Nov 2020 00:26:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605688012; cv=none; d=google.com; s=arc-20160816; b=w/eMnV/7Q3ehno4rzyVyuc96eOrXR/PBOW624z3sYp/aXsMeMD/bOokA/VT0Uaus5r 2m0JOefjFB/bNmd+Jnjh6HsCOLhzVZd6+vBuJehd857yV5IDYgAc60Fg+k2tvbvSQ5v3 LVD/q7E3+7h12f7PetHUlUeRcTRLOqlPKI/GbrlZt2fkPt7NbctkpPk0OWfmBus0D4i4 MTfnhCRhUZ0G31Mh+JUdFoGTnkYjM31Q5Au59rDGM9M60UYpV47DGMoew5+SEHscrDpZ PNBcxVcjhJ5WaNrgs1IC5vndY57VjrFUFRhxd3Aj/a5uD9ov7gJE+j9MqLoqKAi5bfoq L9LA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from; bh=ZHl4tWU5g4cTDGB0GMqDIeGKTvPLnab5Fd8D/0UO11U=; b=gYZM3PzkPmleed1J7gfb3CNLhZJ7MAlwcIuA6nZAXvEBeJt+xl7J85BXOnabrUqhO6 bEPN4E/gSrFcXEIh/aVfepoOUv8F0sK5+U2oIOBGKDcv9WVggG0W8qwEfbr1+sgF1oOL 7FX3o6jDcWInmiZI0D3Hx4bjeoXteFSlCyLESEe+SXjqMyYQG/8Oua1DG/kWwmviNQfJ NTgU1OgTGsz/ZQpASAWBOjuQiusmcqRWYiZeKSjwUkzZ1NzEH92c7Le/2vAZBghje/QC p+I2jvH8TcQOAF5fCgfZLvkVnDLr1Hks6fw5jaTk7L5PGhAP2pi/K39/K753DVLeWe/0 wCBA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k20si16187584edk.392.2020.11.18.00.26.29; Wed, 18 Nov 2020 00:26:52 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726759AbgKRIZP (ORCPT + 99 others); Wed, 18 Nov 2020 03:25:15 -0500 Received: from out30-43.freemail.mail.aliyun.com ([115.124.30.43]:60025 "EHLO out30-43.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726200AbgKRIZP (ORCPT ); Wed, 18 Nov 2020 03:25:15 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R681e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04407;MF=xuanzhuo@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0UFmyUVT_1605687910; Received: from localhost(mailfrom:xuanzhuo@linux.alibaba.com fp:SMTPD_---0UFmyUVT_1605687910) by smtp.aliyun-inc.com(127.0.0.1); Wed, 18 Nov 2020 16:25:10 +0800 From: Xuan Zhuo To: bjorn.topel@intel.com Cc: Magnus Karlsson , Jonathan Lemon , "David S. Miller" , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/3] xsk: fix for xsk_poll writeable Date: Wed, 18 Nov 2020 16:25:07 +0800 Message-Id: X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <3306b4d8-8689-b0e7-3f6d-c3ad873b7093@intel.com> References: <3306b4d8-8689-b0e7-3f6d-c3ad873b7093@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I tried to combine cq available and tx writeable, but I found it very difficult. Sometimes we pay attention to the status of "available" for both, but sometimes, we may only pay attention to one, such as tx writeable, because we can use the item of fq to write to tx. And this kind of demand may be constantly changing, and it may be necessary to set it every time before entering xsk_poll, so setsockopt is not very convenient. I feel even more that using a new event may be a better solution, such as EPOLLPRI, I think it can be used here, after all, xsk should not have OOB data ^_^. However, two other problems were discovered during the test: * The mask returned by datagram_poll always contains EPOLLOUT * It is not particularly reasonable to return EPOLLOUT based on tx not full After fixing these two problems, I found that when the process is awakened by EPOLLOUT, the process can always get the item from cq. Because the number of packets that the network card can send at a time is actually limited, suppose this value is "nic_num". Once the number of consumed items in the tx queue is greater than nic_num, this means that there must also be new recycled items in the cq queue from nic. In this way, as long as the tx configured by the user is larger, we won't have the situation that tx is already in the writeable state but cannot get the item from cq. Xuan Zhuo (3): xsk: replace datagram_poll by sock_poll_wait xsk: change the tx writeable condition xsk: set tx/rx the min entries include/uapi/linux/if_xdp.h | 2 ++ net/xdp/xsk.c | 26 ++++++++++++++++++++++---- net/xdp/xsk_queue.h | 6 ++++++ 3 files changed, 30 insertions(+), 4 deletions(-) -- 1.8.3.1