Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755714AbbBGBpx (ORCPT ); Fri, 6 Feb 2015 20:45:53 -0500 Received: from mail-qc0-f177.google.com ([209.85.216.177]:37576 "EHLO mail-qc0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753864AbbBGBpv (ORCPT ); Fri, 6 Feb 2015 20:45:51 -0500 MIME-Version: 1.0 In-Reply-To: <54D4651D.6060300@gmail.com> References: <1423115891-3578-1-git-send-email-al.drozdov@gmail.com> <54D4651D.6060300@gmail.com> From: Willem de Bruijn Date: Fri, 6 Feb 2015 17:45:20 -0800 Message-ID: Subject: Re: [PATCH] af_packet: don't pass empty blocks for PACKET_V3 To: Alexander Drozdov Cc: "David S. Miller" , Daniel Borkmann , Eric Dumazet , Al Viro , "Michael S. Tsirkin" , Network Development , linux-kernel , Guy Harris , Dan Collins Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3349 Lines: 79 On Thu, Feb 5, 2015 at 10:54 PM, Alexander Drozdov wrote: > On 05.02.2015 23:01:38 +0300 Willem de Bruijn wrote: >> >> On Wed, Feb 4, 2015 at 9:58 PM, Alexander Drozdov >> wrote: >>> >>> Don't close an empty block on timeout. Its meaningless to >>> pass it to the user. Moreover, passing empty blocks wastes >>> CPU & buffer space increasing probability of packets >>> dropping on small timeouts. >>> >>> Side effect of this patch is indefinite user-space wait >>> in poll on idle links. But, I believe its better to set >>> timeout for poll(2) when needed than to get empty blocks >>> every millisecond when not needed. >> >> This change would break existing applications that have come >> to depend on the periodic signal. >> >> I don't disagree with the argument that the data ready signal >> should be sent only when a block is full or a timer expires and >> at least some data is waiting, but that is moot at this point. > > I missed something. As pointed by Guy Harris , > before the previous patch periodic signal was not delivered. The previous > patch > (da413eec729dae5dc by Dan Collins ) is for 3.19 kernel > only. Should we care about existing 3.19-only applications? It does sound reasonable to expect processes to handle infinite sleep on no data if that is the historical behavior of the interface. >> >>> Signed-off-by: Alexander Drozdov >>> --- >>> net/packet/af_packet.c | 10 +++++++++- >>> 1 file changed, 9 insertions(+), 1 deletion(-) >>> >>> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c >>> index 9cfe2e1..9a2f70a 100644 >>> --- a/net/packet/af_packet.c >>> +++ b/net/packet/af_packet.c >>> @@ -698,6 +698,10 @@ static void prb_retire_rx_blk_timer_expired(unsigned >>> long data) >>> >>> if (pkc->last_kactive_blk_num == pkc->kactive_blk_num) { >>> if (!frozen) { >>> + if (!BLOCK_NUM_PKTS(pbd)) { >>> + /* An empty block. Just refresh the >>> timer. */ >>> + goto refresh_timer; >>> + } >>> prb_retire_current_block(pkc, po, >>> TP_STATUS_BLK_TMO); >>> if (!prb_dispatch_next_block(pkc, po)) >>> goto refresh_timer; >>> @@ -798,7 +802,11 @@ static void prb_close_block(struct tpacket_kbdq_core >>> *pkc1, >>> h1->ts_last_pkt.ts_sec = last_pkt->tp_sec; >>> h1->ts_last_pkt.ts_nsec = last_pkt->tp_nsec; >>> } else { >>> - /* Ok, we tmo'd - so get the current time */ >>> + /* Ok, we tmo'd - so get the current time. >>> + * >>> + * It shouldn't really happen as we don't close empty >>> + * blocks. See prb_retire_rx_blk_timer_expired(). >>> + */ >>> struct timespec ts; >>> getnstimeofday(&ts); >>> h1->ts_last_pkt.ts_sec = ts.tv_sec; >>> -- >>> 1.9.1 >>> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/