From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id 5B2A81B322 for ; Mon, 30 Oct 2017 15:24:15 +0100 (CET) Received: by mail-wm0-f67.google.com with SMTP id t139so16831303wmt.1 for ; Mon, 30 Oct 2017 07:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=tzAHQ1ryNLEvlSNd3QfeYmDmmoFG/HhSmTYhZeXNO40=; b=I4W2us+MoyaWiG/D6Pyr9EREG6es2Spqb2uKMfJFqWo8oUYjZGuwK/ZIu+qfRcKtp+ f9tQ1CVv8fpLAxj02lPJa+YcX4fgozqxp+0kbduGN6OLlIE5MCEftyFI2I7sSjKl3QbI TXViv0vl5H/59Q5yv3lGycTpT6d0KA/7ursU2ZA47vL8J2G1+YDWQgPpEwbSoHZIG5br mpq+M5wxGMGkh26xEDOPSz/jku/7a4YLkQ4UcNxleqeiYeDetpiT/HmQRrTLPKn+EeQY WvDOBYECu/5Ht/cRSt0+rBHNrVfiisNw9OMKIpRtdNbqpmFDaL9TVWcXEk1yRYqMqjOG dzgQ== 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=tzAHQ1ryNLEvlSNd3QfeYmDmmoFG/HhSmTYhZeXNO40=; b=S9K/hBXaaAnL+rvOubJ+9Ql2g1jjRHTYPz14ug2xJwUU0e4ecmewjYnKhD5+hTjCoD pqeXSCB30kPWg5J1NRPeikmpP+rC8bQOEJI6BCS5pc14y+adIrySGhSQ2W4FH6+O27pm 3jXCdJ4JnayXTuFD6pPBXrkUdoV5wVXT3pxaKVXEFH0mImJp5yHTSgnwS77Sw1eOmnkH ib7Udg69TNl5ABXUkGMMUVgfBO9sA+JVjDvxFZ0erQCTT0Pz7cA9RgDWjzJygl12bZpu +JLTooCiaxXFcabM73IoyV2qAjeMQwUIcAaLdCNmLL4/kAeCrPVLBYAqstqYbcK2sOLi jykQ== X-Gm-Message-State: AMCzsaXnvPDoVtTRBCN2tkKbQiSF9eLJLx5LigRaciIKguyJ4C5QNsm0 KNPsFqHgtwkg2OLZc3AUmSdeZg== X-Google-Smtp-Source: ABhQp+TCKXcr3V3dpLdWXtL62i+SHdBqe69R2yo7Xv6bH/2TEL+Ay6fQ2aiEGaKnhJ3sfkNsWTIdbQ== X-Received: by 10.28.131.200 with SMTP id f191mr4234981wmd.39.1509373455098; Mon, 30 Oct 2017 07:24:15 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id e131sm4362188wmg.15.2017.10.30.07.24.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 07:24:14 -0700 (PDT) Date: Mon, 30 Oct 2017 15:24:03 +0100 From: Adrien Mazarguil To: Matan Azrad Cc: dev@dpdk.org, Ophir Munk Message-ID: <20171030142403.GD26782@6wind.com> References: <1508768520-4810-1-git-send-email-ophirmu@mellanox.com> <1509358049-18854-1-git-send-email-matan@mellanox.com> <1509358049-18854-8-git-send-email-matan@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1509358049-18854-8-git-send-email-matan@mellanox.com> Subject: Re: [dpdk-dev] [PATCH v3 7/7] net/mlx4: remove empty Tx segment support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 14:24:16 -0000 On Mon, Oct 30, 2017 at 10:07:29AM +0000, Matan Azrad wrote: > Move empty segment case processing to debug mode. > > Signed-off-by: Matan Azrad Whoa, I think there's a misunderstanding here. Nothing prevents applications from attempting to send zero-length segments, and the PMD must survive this somehow. I think this commit should be dropped, more below. > --- > drivers/net/mlx4/mlx4_rxtx.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/mlx4/mlx4_rxtx.c b/drivers/net/mlx4/mlx4_rxtx.c > index 482c399..c005a41 100644 > --- a/drivers/net/mlx4/mlx4_rxtx.c > +++ b/drivers/net/mlx4/mlx4_rxtx.c > @@ -305,15 +305,18 @@ static int handle_multi_segs(struct rte_mbuf *buf, > return -1; > } > #endif /* NDEBUG */ > - if (likely(sbuf->data_len)) { > - byte_count = rte_cpu_to_be_32(sbuf->data_len); > - } else { > + byte_count = rte_cpu_to_be_32(sbuf->data_len); > +#ifndef NDEBUG > + if (unlikely(!sbuf->data_len)) { > + DEBUG("%p: Empty segment is not allowed", > + (void *)txq); > /* > * Zero length segment is treated as inline segment > * with zero data. > */ > byte_count = RTE_BE32(0x80000000); > } > +#endif /* NDEBUG */ This change means outside of debug mode and according to PRM, a zero-length segment is interpreted as containing 2 GiB worth of data, which guarantees some sort of crash. To properly enforce such a limitation, you'd need a check (possibly unlikely()) to reject the packet and stop the TX function at this point anyway. Such a check negates any kind of optimization brought by this commit, as small as it is. You'd better leave the existing code unmodified in my opinion. -- Adrien Mazarguil 6WIND