From owner-freebsd-net@freebsd.org Tue Mar 20 08:21:28 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 DFFB2F5D16B for ; Tue, 20 Mar 2018 08:21:27 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75A90868F5 for ; Tue, 20 Mar 2018 08:21:27 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-qk0-x234.google.com with SMTP id s9so705455qke.12 for ; Tue, 20 Mar 2018 01:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RPppaJkBVdVALYPw6cnnRszWdZG9mt4Zs/p/IFanXDo=; b=GQ3Y8SjcrY0AdCWnJ0vjKEt9XOxbdOHqaxNQ7cCZgpda1LXIq02h/jZ4N1w1pNQktj nCunx6CXEKv/MYlUVn2ORTtrFIRKQYxcy4ZJUdBsjwPxolDiMW+UhJJ4HgcmRyl8TJl5 m405I8aYQg3ZwfkkTVBOGfWb+2xC5BqtzlsxwnMUJXGvTGXgEFtVLbIkeaXFcy2x2NlI lzCTFfwSV0zDNFNAntf7cbWtysx+s7juCmMaEfLLCbo9X9BBjIgrnCmq8ZXo7ZZmp9yG PFfx1QSONf62aoEvWgPkK1OgSIuzHd4WmqCAsaX2z0pkWx7TY9YA1x9gANbUkM0nD/E0 nYFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RPppaJkBVdVALYPw6cnnRszWdZG9mt4Zs/p/IFanXDo=; b=BKoU8S/P7OzDXsREu1mrjejXkhJ74oU0sK6MbbPbUFTusYH22n1X8NbPvj+hKqbM2f y5B2iUnQ9QRvUa59KvBxZneKmvKzfSVOvYHxZ7+pWiZ2ioiIuCPavBgafMbsQUTNpYz1 lyU+P4NkPo6YfGfD8oUI4E+B+dFd647WtvarKQUmdnl9gEDbePOkElHDlHaPuvoFg6yS k/LrzNMhxkFTATjwI5zKubhjBeRFj3J30cMe7lQUrEyymXtrlCRu/8lbLGjhGYew4w7A fYYHyvhPm2y49no1Kf+kjfx0n7PpGwP6ZZi5pAF+mxhOV7A3doQcK/cSVfLYICEzxmqU cGeQ== X-Gm-Message-State: AElRT7GKUsCzXxNMP+rDhLzq8YhBjrb282Lv5sOLDwKe+/5kzwMklF4z 5Q36hFh30KWHHL6nzKB3bI3rNAMLOp29m9pax6g= X-Google-Smtp-Source: AG47ELv9gn6XCtSyMxfZU+8kU1pl4EcTrAdihT0YwOzwVXqRbPeZrvu+abqM/2rfbRKvKwUaFx8aR3UdJxv+B2G76xo= X-Received: by 10.233.235.2 with SMTP id b2mr22662205qkg.27.1521534086843; Tue, 20 Mar 2018 01:21:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.195.204 with HTTP; Tue, 20 Mar 2018 01:21:26 -0700 (PDT) In-Reply-To: <5AB01439.3090003@cox.net> References: <5AAC49BE.3030508@cox.net> <5AAC4A96.1040107@cox.net> <5AB01439.3090003@cox.net> From: Vincenzo Maffione Date: Tue, 20 Mar 2018 09:21:26 +0100 Message-ID: Subject: Re: netmap ixgbevf mtu To: Joe Buehler Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 08:21:28 -0000 2018-03-19 20:49 GMT+01:00 Joe Buehler : > Vincenzo Maffione wrote: > > > To receive a frame larger than the RX buffer size you need multiple > > netmap slots (as multiple descriptors are > > used by the hardware), looking at the NS_MOREFRAG flag. > > See the example code in utils/functional.c::rx_one(). > > This works fine -- thanks. > > > Also TX may have per-slot limitations (e.g. due to the size of the NIC > > TX fifo), but this is usually > 9K, so using a single descriptor per > > packet should always > > be ok. However, you can also use multiple slots on the TX side (see > > utils/functional.c::tx_one()). > > Trying to split TX frames into multiple buffers does not work, the NIC is > sending 2048 byte frames (the buf_size I am using). > > I will re-check my code. Do I need a particular version of ixgbevf > perhaps? > > 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