From owner-freebsd-net@freebsd.org Tue Mar 20 18:42:46 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14EF6F64B63 for ; Tue, 20 Mar 2018 18:42:46 +0000 (UTC) (envelope-from aspam@cox.net) Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by mx1.freebsd.org (Postfix) with ESMTP id AC99E81840 for ; Tue, 20 Mar 2018 18:42:45 +0000 (UTC) (envelope-from aspam@cox.net) Received: from eastrmimpo210.cox.net ([68.230.241.225]) by eastrmfepo201.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180320184239.VBTG1466.eastrmfepo201.cox.net@eastrmimpo210.cox.net> for ; Tue, 20 Mar 2018 14:42:39 -0400 Received: from thunder.sweets ([68.100.138.62]) by eastrmimpo210.cox.net with cox id QJif1x0081LxgH801JifpX; Tue, 20 Mar 2018 14:42:39 -0400 X-Authority-Analysis: v=2.2 cv=fefd8wYF c=1 sm=1 tr=0 a=3mkzfl4ircflX6G+lDqBYw==:117 a=3mkzfl4ircflX6G+lDqBYw==:17 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=v2DPQv5-lfwA:10 a=e9ASbk4n0QUA:10 a=NEAV23lmAAAA:8 a=P-IC7800AAAA:8 a=QyXUC8HyAAAA:8 a=iFnR9IgGT0Xcdpwh32IA:9 a=BXztF5QcbhpWnWO5:21 a=ZFuU1ysdDbrGSKE0:21 a=QEXdDO2ut3YA:10 a=d3PnA9EDa4IxuAV0gXij:22 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=jbuehler@cox.net Received: from [10.10.10.15] (thunder.sweets [10.10.10.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thunder.sweets (Postfix) with ESMTP id E5CCD1152A; Tue, 20 Mar 2018 14:42:38 -0400 (EDT) Message-ID: <5AB1561D.7010608@cox.net> Date: Tue, 20 Mar 2018 14:42:37 -0400 From: Joe Buehler User-Agent: Thunderbird 1.5.0.12 (X11/20120201) MIME-Version: 1.0 To: Vincenzo Maffione CC: "freebsd-net@freebsd.org" Subject: Re: netmap ixgbevf mtu References: <5AAC49BE.3030508@cox.net> <5AAC4A96.1040107@cox.net> <5AB01439.3090003@cox.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 18:42:46 -0000 If you could fix this I would appreciate it. My L1 TX performance for 64 byte L2 frames drops significantly, from about 9 gigbits to 7 gigabits, when I use buffers large enough to hold jumbo frames. I will play with it a bit locally. One thing that occurs to me is to pass the full frame length when NS_MOREFRAG is set and have the driver assume that the buffer is full if that length is more than the buffer length. That way netmap knows both the total length and the fragment length. Very ugly but... Joe Buehler > I don't think so, but you need to use the latest netmap from github. > The NS_MOREFRAG support for ixgbe/ixgbevf is here > https://github.com/luigirizzo/netmap/blob/master/LINUX/ixgbe_netmap_linux.h#L344-L345 > > The problem is that nobody really tried to use NS_MOREFRAG on ixgbevf > transmission so far. > So there may be a bug on how we set the flags in the hardware descriptor. > We should look at what the driver does. Here > https://elixir.bootlin.com/linux/v3.8/source/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c#L2903 > I see that the olinfo_status field is set with the total frame length > (and not just the fragment length). > In the netmap code we set to the fragment length, so that's probably why > you see that behaviour. > Here > https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/82599-10-gbe-controller-datasheet.pdf > in sec. 7.2.3.2.4 I read that we need to properly set the olinfo_status > field on the firsts TX descriptor, while the others are irrelevant. > > Cheers, > Vincenzo > > > > > > Joe Buehler > > > > > -- > Vincenzo Maffione