From owner-freebsd-net@freebsd.org Sun Jan 3 10:35:24 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE021A5F1C3 for ; Sun, 3 Jan 2016 10:35:24 +0000 (UTC) (envelope-from mailhuanhuan@gmail.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 C84501383 for ; Sun, 3 Jan 2016 10:35:24 +0000 (UTC) (envelope-from mailhuanhuan@gmail.com) Received: by mail-pa0-x234.google.com with SMTP id uo6so162110140pac.1 for ; Sun, 03 Jan 2016 02:35:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:subject:message-id:user-agent:mime-version :content-type; bh=f4SH3B9PLoEuIMOQ94jSp2WY4DNyMq2Xif3m7HphzYA=; b=zLw0cAAdQ+JamxnStw7FtACLWpQBqFsiOBVpWfX10H58zA+QZPtusqrdJ66wIK8XVj 4tePRfE7LDqG0Ht8xfgn6pU0GWVfBnQ/7ZcCIKN1bBHkoOzpZ1aBpoHxUHVrrKO5wDh+ rEg2avaO+vTHmpMcGu/dmWTsPsefg7l9r59FHy6nQRCCbCsPDPmLQSrDuC+Pp40FIaX8 yhvA+doX/jg2IffEaMb8ijF8CEHtCTIZOV7BHdvYHYCmBzpXWxQW3v5CrI6dvw+WqGFL Jg3sVIdrVXGBUYOi2ft1FAOy8LumSu7vPpRDAsbP3R5xiNWmwoV9X81T0vbweD6+pxCn 2gNA== X-Received: by 10.66.197.131 with SMTP id iu3mr98668629pac.57.1451817324345; Sun, 03 Jan 2016 02:35:24 -0800 (PST) Received: from [192.168.255.2] ([104.207.154.124]) by smtp.gmail.com with ESMTPSA id x75sm51707091pfi.95.2016.01.03.02.35.22 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jan 2016 02:35:23 -0800 (PST) From: HuanHuan X-Google-Original-From: HuanHuan Date: Sun, 3 Jan 2016 18:34:47 +0800 (CST) To: freebsd-net@freebsd.org Subject: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 10:35:25 -0000 NetBSD 7.0 has just introduced these two syscalls. And Linux also has them. Does FreeBSD have them? Or plan to support them in the future? Thank you for reading this. From owner-freebsd-net@freebsd.org Sun Jan 3 17:10:06 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B59E3A5FEAB for ; Sun, 3 Jan 2016 17:10:06 +0000 (UTC) (envelope-from rpaulo@me.com) Received: from mr11p00im-asmtp002.me.com (mr11p00im-asmtp002.me.com [17.110.69.253]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4A781551 for ; Sun, 3 Jan 2016 17:10:06 +0000 (UTC) (envelope-from rpaulo@me.com) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8 Received: from akita.hsd1.ca.comcast.net (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by mr11p00im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O0D00NRTZOTW330@mr11p00im-asmtp002.me.com> for freebsd-net@freebsd.org; Sun, 03 Jan 2016 17:10:06 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-01-03_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1601030324 Message-id: <1451841004.10139.34.camel@me.com> Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Rui Paulo To: HuanHuan , freebsd-net@freebsd.org Date: Sun, 03 Jan 2016 09:10:04 -0800 In-reply-to: References: X-Mailer: Evolution 3.18.3-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 17:10:06 -0000 On Sun, 2016-01-03 at 18:34 +0800, HuanHuan wrote: > NetBSD 7.0 has just introduced these two syscalls. > And Linux also has them. > > Does FreeBSD have them? Or plan to support them in the future? FreeBSD does not have them.  It doesn't seem especially hard to implement, though.  Do you know any major application already using them? -- Rui Paulo From owner-freebsd-net@freebsd.org Sun Jan 3 17:46:38 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4BA4A60B4D for ; Sun, 3 Jan 2016 17:46:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id B78D710BE for ; Sun, 3 Jan 2016 17:46:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 841BD46B59; Sun, 3 Jan 2016 12:46:37 -0500 (EST) Date: Sun, 3 Jan 2016 17:46:37 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rui Paulo cc: HuanHuan , freebsd-net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <1451841004.10139.34.camel@me.com> Message-ID: References: <1451841004.10139.34.camel@me.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 17:46:38 -0000 On Sun, 3 Jan 2016, Rui Paulo wrote: >> NetBSD 7.0 has just introduced these two syscalls. And Linux also has them. >> >> Does FreeBSD have them? Or plan to support them in the future? > > FreeBSD does not have them.  It doesn't seem especially hard to implement, > though.  Do you know any major application already using them? I see no harm in having the system calls. When I chatted with the authors of nsd a couple of years ago (they had originally promoted the approach), they told me they felt it only offered incremental benefit and didn't particularly recommend that FreeBSD adopt it. However, it would undoubtably see use and does offer some opportunities for future batching-related performance operations, so if someone wants to pursue introducing it, do go ahead. Or just introduce a libc implementation that can be converted to a kernel implementation later if that is determined to be beneficial. But the nsd observations don't (currently) lead me to believe that it is critical to do so. Robert From owner-freebsd-net@freebsd.org Sun Jan 3 18:02:38 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6B66A60342 for ; Sun, 3 Jan 2016 18:02:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 8CDD213B5; Sun, 3 Jan 2016 18:02:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22d.google.com with SMTP id 1so91832257ion.1; Sun, 03 Jan 2016 10:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=loCPEqvGbDPBPwjC1sMJUfIFn9ap9SL2erM9ZwmsKWY=; b=AVQnAudXRUccKRTDcTIK9gcDWn89FMeyaCZGtcz6uGosy7K6Jx2a/UXn6OCEbMDcbD IGflhxufui7Q+BVNiNAZ0uXjScZr8QNpxPu0HnAPxKWJ0BrBVCPUCadT81AUIPplJ7V5 Z4VW603y+GJUCj8+DOTN0lyjztNlaT/6mslENE/wl82USTtGvIxLD8tVGGLvziX5WF0+ TtWjG/FPyWUsOhgrEWTZbjUeIRIaAwgiGbcp+OOu/1ZPLnsaPSH0dY9G/UgTo2/vHWZ2 /XBZZQEQglkkl5TH+G0Zyhn6j+JAZJ+3t4v6+kd7A54hwjaQVn8QKn5xoT63lPeDk3MB R+hA== MIME-Version: 1.0 X-Received: by 10.107.162.146 with SMTP id l140mr21286164ioe.123.1451844157937; Sun, 03 Jan 2016 10:02:37 -0800 (PST) Received: by 10.36.121.202 with HTTP; Sun, 3 Jan 2016 10:02:37 -0800 (PST) In-Reply-To: References: <1451841004.10139.34.camel@me.com> Date: Sun, 3 Jan 2016 10:02:37 -0800 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Adrian Chadd To: Robert Watson Cc: Rui Paulo , HuanHuan , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 18:02:38 -0000 On 3 January 2016 at 09:46, Robert Watson wrote: > On Sun, 3 Jan 2016, Rui Paulo wrote: > >>> NetBSD 7.0 has just introduced these two syscalls. And Linux also has >>> them. >>> >>> Does FreeBSD have them? Or plan to support them in the future? >> >> >> FreeBSD does not have them. It doesn't seem especially hard to implement, >> though. Do you know any major application already using them? > > > I see no harm in having the system calls. When I chatted with the authors > of nsd a couple of years ago (they had originally promoted the approach), > they told me they felt it only offered incremental benefit and didn't > particularly recommend that FreeBSD adopt it. However, it would undoubtably > see use and does offer some opportunities for future batching-related > performance operations, so if someone wants to pursue introducing it, do go > ahead. Or just introduce a libc implementation that can be converted to a > kernel implementation later if that is determined to be beneficial. But the > nsd observations don't (currently) lead me to believe that it is critical to > do so. There's a paper from Yahoo! from a while ago where they did, among other things, add this functionality (to linux.) It doesn't help at low connection rates. It helps at high connection / concurrency rates as the time going in/out of the kernel and getting back to steady state execution changes. I can't find the paper off-hand, but it is out there. I can benchmark it on my UDP RSS stuff and see if it helps at the highest connection rates. :) -adrian From owner-freebsd-net@freebsd.org Sun Jan 3 18:42:55 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22BADA5F127 for ; Sun, 3 Jan 2016 18:42:55 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (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 A45131BE0; Sun, 3 Jan 2016 18:42:54 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lb0-x22e.google.com with SMTP id pv2so164579326lbb.1; Sun, 03 Jan 2016 10:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GEof0u9QZXzpazSUvDokdToRla7SoV7NrF+HgUQX2PE=; b=ym513fbVsXkCOjQNPbrD0w36uOzOLK8lQo2V+i2rLepLkgt3/eoJe0ZyfxivCK03IR I0tF1KV4d1tGc4ilWZe/3JDcW0qtfHE3OYp2nc5yrnnxSytWvr1NkXxp1ypA3/dA1nbb t7UQB7pxtnfQvGMLM2PF1F9b3J8OSbgch6MKPiZoixMN6XQ3v2WEUtBnOlpFuZ0p7pl9 i03cORT5wZQ+f4rFudCVL1L7AkPIwb3Up4ZKvDbD/OX34EMs2C6BoUZhESnYW/JRir65 gSL9bKbwyK5V2VjJN7Vgg6nt2s5i3mslJXH/WqFIR+97LxIieWOGJ/BJSimLvOkG73jS TtWg== MIME-Version: 1.0 X-Received: by 10.112.211.136 with SMTP id nc8mr29751507lbc.54.1451846572693; Sun, 03 Jan 2016 10:42:52 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.13.33 with HTTP; Sun, 3 Jan 2016 10:42:52 -0800 (PST) In-Reply-To: References: <1451841004.10139.34.camel@me.com> Date: Sun, 3 Jan 2016 19:42:52 +0100 X-Google-Sender-Auth: V3jYoCmzx4GR-T_qS8IpzBsNfDE Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Luigi Rizzo To: Robert Watson Cc: Rui Paulo , HuanHuan , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 18:42:55 -0000 On Sun, Jan 3, 2016 at 6:46 PM, Robert Watson wrote: > On Sun, 3 Jan 2016, Rui Paulo wrote: > >>> NetBSD 7.0 has just introduced these two syscalls. And Linux also has >>> them. >>> >>> Does FreeBSD have them? Or plan to support them in the future? >> >> >> FreeBSD does not have them. It doesn't seem especially hard to implement, >> though. Do you know any major application already using them? > > > I see no harm in having the system calls. When I chatted with the authors > of nsd a couple of years ago (they had originally promoted the approach), > they told me they felt it only offered incremental benefit and didn't > particularly recommend that FreeBSD adopt it. However, it would undoubtably > see use and does offer some opportunities for future batching-related > performance operations, so if someone wants to pursue introducing it, do go > ahead. Or just introduce a libc implementation that can be converted to a > kernel implementation later if that is determined to be beneficial. But the > nsd observations don't (currently) lead me to believe that it is critical to > do so. Do not expect great speedups unless you are willing to put a ton of work in the network stack. When I looked at it (about 2012), the linux implementation for sendmmsg() just looped inside the kernel on the body of sendmsg(), so the advantage was just in the syscall enter/exit call, which on linux again was relatively cheap anyways. So think of some 10% gain for unconnected sockets on every msg after the first one, and maybe slightly larger on connected sockets. It is not easy to do better, especially for unconnected sockets, because you have to lookup addresses for each message, possibly going to different interfaces, so unless you are willing to implement batching throughout the entire stack you won't see much gain. On the receive side, the syscall is probably another story (one can grab a full batch of packets in one shot), though the expensive part of the work -- dispatching packets to the socket -- was already done on the receive interrupt handler. Same problems as in the tx path to be solved. cheers luigi From owner-freebsd-net@freebsd.org Sun Jan 3 21:00:03 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C60F6A5FBE3 for ; Sun, 3 Jan 2016 21:00:03 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC80E175D for ; Sun, 3 Jan 2016 21:00:03 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u03L01gA078656 for ; Sun, 3 Jan 2016 21:00:03 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201601032100.u03L01gA078656@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention Date: Sun, 03 Jan 2016 21:00:03 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 21:00:03 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 203422 | mpd/ppoe not working with re(4) with revision 285 New | 203175 | Daily kernel crashes in tcp_twclose
Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0775CA60A90 for ; Sun, 3 Jan 2016 21:33:16 +0000 (UTC) (envelope-from mailhuanhuan@gmail.com) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 D27691354 for ; Sun, 3 Jan 2016 21:33:15 +0000 (UTC) (envelope-from mailhuanhuan@gmail.com) Received: by mail-pa0-x232.google.com with SMTP id uo6so166507522pac.1 for ; Sun, 03 Jan 2016 13:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; bh=uagUmBa/9RX0xa0zTzCVOyaojkgbtlXKPasLm13dZuM=; b=xQSo+IAcamsfLCCgJRQsbSu9JioU3+FK54HwPQOJZAWHdRocpTFfNPDATrAmOtIxcj ITNitFYgD6jWHgB4QWYgCGtQE2rbtzE2jDbGlfSYW+23R9Y0QAMbVmtz9zdRCTXeHdjJ ceYUqS1mJfJ6t19KWncuJ4KcQysDGJKLEcKKvA0SX1TcsakQX13rbFG1LETNC+6BJ45T kZ0fPV2/mkNnDZUTU+cbzVQd7UsnfXxOb7FsYgVFkJuNtslRaE1Hbn9I53fTDwzd4W+5 oLra5rtgYorcqPoVQeoKz28+z9ZyP117E+/zYPM317KoWYUbaMVALOnJRDMMxMvrpPYz aaNQ== X-Received: by 10.66.253.97 with SMTP id zz1mr79530729pac.106.1451856795285; Sun, 03 Jan 2016 13:33:15 -0800 (PST) Received: from [192.168.255.2] ([104.207.154.124]) by smtp.gmail.com with ESMTPSA id 7sm116076617pfb.62.2016.01.03.13.33.12 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jan 2016 13:33:14 -0800 (PST) From: HuanHuan X-Google-Original-From: HuanHuan Date: Mon, 4 Jan 2016 05:32:36 +0800 (CST) To: Rui Paulo cc: HuanHuan , freebsd-net@freebsd.org, Luigi Rizzo Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <1451841004.10139.34.camel@me.com> Message-ID: References: <1451841004.10139.34.camel@me.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 21:33:16 -0000 Hi Rui, There are no existing applications, but these two calls are for developing new application on 10G links. Currently I use netgraph, especially ng_socket node. And a simple recvfrom() on a ng_socket costs ~5us or so (200K per second). And there are many netgraph sockets. So it's good to reduce the time by ultilizing send/recvmmsg() if there are these two syscalls. Even a simple-loop like implmentation like linux's will be good as Luigi has suggested. On Sun, 3 Jan 2016, Rui Paulo wrote: > On Sun, 2016-01-03 at 18:34 +0800, HuanHuan wrote: >> NetBSD 7.0 has just introduced these two syscalls. >> And Linux also has them. >> >> Does FreeBSD have them? Or plan to support them in the future? > > FreeBSD does not have them.  It doesn't seem especially hard to > implement, though.  Do you know any major application already using > them? > > -- > Rui Paulo > > From owner-freebsd-net@freebsd.org Sun Jan 3 21:47:22 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AA95A60FAF for ; Sun, 3 Jan 2016 21:47:22 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: from f5.bushwire.net (f5.bushwire.net [IPv6:2607:fc50:1000:5b00::2]) by mx1.freebsd.org (Postfix) with ESMTP id 316671999 for ; Sun, 3 Jan 2016 21:47:21 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: by f5.bushwire.net (Postfix, from userid 1001) id 03718AC908; Sun, 3 Jan 2016 13:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2015; t=1451857641; bh=HkFM0YnXVjWd+c2Og6SCgVNr6P8=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=p0OUahspntnNYEAXLPa1Igq7E+LLDGpSe9vEzONxdum2wTgCv+n7Si7IYzCCM3gkP FWPRHlTW8160Wgl01Pbd59h2hze02pByYpdxumXMDYDKFgp6T349TvtAUp+d+SCVsd qToAX6s+vqSVzSjJ9OhUVpeCQzhdJlVJKOVc5vyQ=c5vyQ= Comments: QMDA 0.3 Received: (qmail 72015 invoked by uid 1001); 3 Jan 2016 21:47:20 -0000 Date: 3 Jan 2016 21:47:20 +0000 Message-ID: <20160103214720.72014.qmail@f5-external.bushwire.net> From: "Mark Delany" To: freebsd-net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? References: <1451841004.10139.34.camel@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 21:47:22 -0000 On 03Jan16, Adrian Chadd allegedly wrote: > It doesn't help at low connection rates. It helps at high connection / > concurrency rates as the time going in/out of the kernel and getting > back to steady state execution changes. This is what I found when I did a comparison at $dayjob. You obviously need more than one message per *mmsg() call to benefit from the syscall amortization which can only occur at very high message rates. It also depends on whether the *mmsg() calls are implemented as mere wrappers around recvmsg() and sendmsg() or whether the implementation goes deeper into the driver to get better batching benefits. (I vaguely thought that one or two drivers in Linux had real recvmmsg() support.) But there are a number of other factors that come into play beyond message rates. The first is that a typical UDP application does very little work per message thus the syscall costs are proportionally more significant than for TCP applications. Eg. DNS or NTP vs HTTP. The second is that a typical syscall sequence of a high performance program likely involves 4 syscalls per packet: select/kqueue/epoll, recvmsg, gettimeofday and sendmsg. The third is that a high performance program probably is multi-threaded so add in a couple of locking syscalls around select/kqueue and you're up to 6 syscalls per request packet. That's a lot of syscalls for an application that might only need a small number of memory references to process a request. The final thing is that on both FBSD and Linux I found a surprising amount of serialization within the UDP socket stack so having multiple threads sit on a blocking recvmsg() at high packet rates is not as productive as you might expect. This level of serialization surprized me given that UDP processing within the kernel should be pretty minimal. Combining all these factors I found it impossible to construct any sort of UDP application that would run any where near line rates on modern beefy machines. It it's not apparent, these are all arguments for implementing *mmsg() calls and for looking at UDP stack serialization. Fortunately for FBSD there is netmap which is moderately well suited to UDP applications... though you still have to do a fair amount of packet decode and encode and it's only applicable in dedicated or specialized deployments. A final observation is that the semantics of *mmsg() may benefit from a bit of scrutiny as they cannot accurately represent some conditions possible with multiple *msg() calls. Eg, if a signal arrives after more than zero packets have been processed by recvmmsg() what is the correct return value? -1 or the count of messages returned? Mark. From owner-freebsd-net@freebsd.org Mon Jan 4 01:33:26 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43F19A61E89; Mon, 4 Jan 2016 01:33:26 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0733D178A; Mon, 4 Jan 2016 01:33:25 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.9/8.14.9) with ESMTP id u041XN4G071894; Sun, 3 Jan 2016 20:33:23 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.9/8.14.4/Submit) id u041XM7m071891; Sun, 3 Jan 2016 20:33:22 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22153.52194.769839.15339@hergotha.csail.mit.edu> Date: Sun, 3 Jan 2016 20:33:22 -0500 From: Garrett Wollman To: "Matthew D. Fuller" Cc: bz@freebsd.org, freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Have I got this VIMAGE setup correct? In-Reply-To: <20151223044233.GM33115@over-yonder.net> References: <22137.33475.645324.203196@hergotha.csail.mit.edu> <20151223044233.GM33115@over-yonder.net> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sun, 03 Jan 2016 20:33:23 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hergotha.csail.mit.edu X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 01:33:26 -0000 < said: >> 2) Stopping jails with virtual network stacks generates warnings from >> UMA about memory being leaked. > I'm given to understand that's Known, and presumably Not Quite Trivial > To Fix. Since I'm not starting/stopping jails repeatedly as a normal > runtime thing, I'm ignoring it. If you were spinning jails up and > down dynamically dozens of times a day, I'd want to look more closely > at just what is leaking and why... It looks like that's what bz@ fixed in r292601 (thanks to rodrigc@ for pointing me in the right direction). I haven't looked at how difficult this would be to backport, but since I'm in the same situation as you in terms of the frequency of startup/teardown operations, I'm probably not going to worry too much about it. Other relevant changes from HEAD appear to be 292603, 292604, 278766, and 286537 (and again, this is just based on scanning the svn logs, not actually thinking about the code). > Is what I'm doing, though I'm creating the epair's and adding them to > the bridges in the setup script rather than rc.conf (exec.prestart in > jail.conf), because that makes it a more manageable IME, and since I'm > already doing a bunch of setup in the script anyway... For now, I think I'll just use exec.prestart to manually configure a MAC address. It would be nice if the LAA MAC addresses we generated were both random on initial creation (to better avoid duplicates) and stable over reboot. (Likewise the bridge(4) MAC address.) Or alternatively if we just had rc.conf support for explicitly configuring the MAC address of every interface, since ifconfig doesn't let you configure L2 and L3 addresses on the same command line. Actually, what would be *really* nice -- and I don't know if any of my network interfaces can do this, but it would give me a reason to buy hardware that could -- would be if PCI virtual functions could be used to implement multiple independent network interfaces in the same kernel (additional units in the same driver). Then I wouldn't have to deal with any of this configuration at all. Failing all of those, having a good, well-documented example in the handbook would be a Good Thing. -GAWollman From owner-freebsd-net@freebsd.org Mon Jan 4 03:11:17 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C62F2A61892 for ; Mon, 4 Jan 2016 03:11:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B287E11CC for ; Mon, 4 Jan 2016 03:11:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u043BDRw024306 for ; Mon, 4 Jan 2016 03:11:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 128030] [ipsec] Enable IPSec in GENERIC kernel configuration Date: Mon, 04 Jan 2016 03:11:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: feature, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: gnn@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 03:11:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D128030 --- Comment #19 from Ed Maste --- > Is there no way to have it enabled in kernel, but disabled by default in = a sysctl OID of some kind if there is a performance hit? Yes, that is exactly the work that was done in -CURRENT to allow it to be compiled in by default, but have a minimal effect on performance unless tu= rned on. I'm not sure how difficult the MFC would be. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Mon Jan 4 04:09:10 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4449A608BC for ; Mon, 4 Jan 2016 04:09:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 B572919FA for ; Mon, 4 Jan 2016 04:09:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x231.google.com with SMTP id mv3so188751309igc.0 for ; Sun, 03 Jan 2016 20:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QjJliis1ML01f3xO+Ho7Nf6C/rZnyAMy0DOyBQmYBxk=; b=kun2bohENgNZMx8IfnB6nsMrjj4Uj1QBJ6fIMJKWshACfNi9qFI1/RyHgf1qw4egGU UkwlTr8itkjNHIfvZ8yw05x1JWd9Cm0zS64zY+D84uYkmoihXMx21FeGPnMzeX5xqham DJU93rqesUMezL0OBvcHJDLyzBiDs/DGzvAr/URX2x9RiHp9/21l/tc8Ee/V3JVPNzem TKK8VsZlV6VlMycHqUl8moXoJdr51Om6BJ5d0FschUQ967mAkXktkUvUimEu83bVQd2J tx3JA6CkupQoZ2b//iXzixsL6A72S5Vj+GtzePkkP3dJIhlFPdHLwKMpNjAWkiIZsY7K 2RYw== MIME-Version: 1.0 X-Received: by 10.50.33.69 with SMTP id p5mr74908258igi.61.1451880550082; Sun, 03 Jan 2016 20:09:10 -0800 (PST) Received: by 10.36.121.202 with HTTP; Sun, 3 Jan 2016 20:09:10 -0800 (PST) In-Reply-To: <20160103214720.72014.qmail@f5-external.bushwire.net> References: <1451841004.10139.34.camel@me.com> <20160103214720.72014.qmail@f5-external.bushwire.net> Date: Sun, 3 Jan 2016 20:09:10 -0800 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Adrian Chadd To: Mark Delany Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 04:09:11 -0000 Hi, Give RSS and the RSS bind options in -HEAD a shot. I can get ~400k pps tx and rx per RSS bucket up to the number of CPU cores / queues supported. (So, I got up to 16 queues on ixgbe on a 2x8 core box with some local hacks.) It scaled linearly. Anything we can do to bump those numbers higher would be great. -a From owner-freebsd-net@freebsd.org Mon Jan 4 06:23:20 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CED6A60BA2 for ; Mon, 4 Jan 2016 06:23:20 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6923A1159 for ; Mon, 4 Jan 2016 06:23:19 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-250-125.lns20.per4.internode.on.net [121.45.250.125]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u046N83U061950 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 3 Jan 2016 22:23:11 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? To: HuanHuan , Rui Paulo References: <1451841004.10139.34.camel@me.com> Cc: freebsd-net@freebsd.org, Luigi Rizzo From: Julian Elischer Message-ID: <568A0FC6.8050107@freebsd.org> Date: Mon, 4 Jan 2016 14:23:02 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 06:23:20 -0000 On 4/01/2016 5:32 AM, HuanHuan wrote: > Hi Rui, > > There are no existing applications, but these two calls are for > developing new application on 10G links. > > Currently I use netgraph, especially ng_socket node. And a simple > recvfrom() on a ng_socket costs ~5us or so (200K per second). And > there are many netgraph sockets. So it's good to reduce the time by > ultilizing send/recvmmsg() if there are these two syscalls. Even a > simple-loop like implmentation like linux's will be good as Luigi > has suggested. As the writer of netgraph I would like to point out that it was never designed to be a high throughput service. I'm happy thought that it CAN be used at these speeds but I designed it for prototyping and for serial line speeds. The idea was that once something was prototyped out, one would take the code from all the modules used and create a special purpose module that dd what you need. The fact that people have not needed the last step is gratifying but surprising. > > On Sun, 3 Jan 2016, Rui Paulo wrote: > >> On Sun, 2016-01-03 at 18:34 +0800, HuanHuan wrote: >>> NetBSD 7.0 has just introduced these two syscalls. >>> And Linux also has them. >>> >>> Does FreeBSD have them? Or plan to support them in the future? >> >> FreeBSD does not have them. It doesn't seem especially hard to >> implement, though. Do you know any major application already using >> them? >> >> -- >> Rui Paulo >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@freebsd.org Mon Jan 4 07:40:42 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F457A60AEB; Mon, 4 Jan 2016 07:40:42 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gilb.zs64.net", Issuer "Cryptonomicore CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 097871645; Mon, 4 Jan 2016 07:40:41 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id BDFC6170F5E; Mon, 4 Jan 2016 07:40:28 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Have I got this VIMAGE setup correct? From: Stefan Bethke In-Reply-To: <22153.52194.769839.15339@hergotha.csail.mit.edu> Date: Mon, 4 Jan 2016 08:40:30 +0100 Cc: freebsd-net@freebsd.org, bz@freebsd.org, FreeBSD Stable Content-Transfer-Encoding: quoted-printable Message-Id: <77DACFE3-ED84-4564-80D8-726B2001084B@lassitu.de> References: <22137.33475.645324.203196@hergotha.csail.mit.edu> <20151223044233.GM33115@over-yonder.net> <22153.52194.769839.15339@hergotha.csail.mit.edu> To: Garrett Wollman X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 07:40:42 -0000 Am 04.01.2016 um 02:33 schrieb Garrett Wollman : >=20 > For now, I think I'll just use exec.prestart to manually configure a > MAC address. It would be nice if the LAA MAC addresses we generated > were both random on initial creation (to better avoid duplicates) and > stable over reboot. (Likewise the bridge(4) MAC address.) Or > alternatively if we just had rc.conf support for explicitly > configuring the MAC address of every interface, since ifconfig doesn't > let you configure L2 and L3 addresses on the same command line. I=E2=80=99ve had good experiences with using create_args_ in = rc.conf. I believe that ifconfig only let=E2=80=99s you work with only one = address family per invocation. Stefan --=20 Stefan Bethke Fon +49 151 14070811 create_args_tap0=3D"ether 02:00:00:00:01:00" create_args_tap1=3D"ether 02:00:00:00:01:01" create_args_tap2=3D"ether 02:00:00:00:01:02" create_args_tap3=3D"ether 02:00:00:00:01:03" create_args_tap4=3D"ether 02:00:00:00:01:04" create_args_vlan100=3D"vlandev em0 vlan 100 up" create_args_vlan101=3D"vlandev em0 vlan 101 up" create_args_vlan102=3D"vlandev em0 vlan 102 up" create_args_vlan103=3D"vlandev em0 vlan 103 up" create_args_vlan104=3D"vlandev em0 vlan 104 up" create_args_bridge100=3D"ether 02:00:00:00:00:64 addm vlan100" create_args_bridge101=3D"ether 02:00:00:00:00:65 addm vlan101" create_args_bridge102=3D"ether 02:00:00:00:00:66 addm vlan102 addm tap0 = addm tap1 fib 1" create_args_bridge103=3D"ether 02:00:00:00:00:67" create_args_bridge104=3D"ether 02:00:00:00:00:68" From owner-freebsd-net@freebsd.org Mon Jan 4 08:54:23 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AFB2A60779 for ; Mon, 4 Jan 2016 08:54:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11480127B for ; Mon, 4 Jan 2016 08:54:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u048sHe9009756 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 4 Jan 2016 10:54:17 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u048sHe9009756 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u048sF0q009755; Mon, 4 Jan 2016 10:54:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 4 Jan 2016 10:54:15 +0200 From: Konstantin Belousov To: Mark Delany Cc: freebsd-net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160104085415.GS3625@kib.kiev.ua> References: <1451841004.10139.34.camel@me.com> <20160103214720.72014.qmail@f5-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160103214720.72014.qmail@f5-external.bushwire.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 08:54:23 -0000 On Sun, Jan 03, 2016 at 09:47:20PM +0000, Mark Delany wrote: > Eg, if a signal arrives after > more than zero packets have been processed by recvmmsg() what is the > correct return value? -1 or the count of messages returned? This is really not a question to consider different answers. Unix already made a (right, IMO) decision there, e.g. for read(2) syscall. If any data was actually read, the length of the consumed data must be returned, and not the error. Typically, socket functions return error on the next call, if the current call must still return data. This is why so_error is there. From owner-freebsd-net@freebsd.org Mon Jan 4 09:11:09 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08335A610D7 for ; Mon, 4 Jan 2016 09:11:09 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: from f5.bushwire.net (f5.bushwire.net [IPv6:2607:fc50:1000:5b00::2]) by mx1.freebsd.org (Postfix) with ESMTP id E3C741C19 for ; Mon, 4 Jan 2016 09:11:08 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: by f5.bushwire.net (Postfix, from userid 1001) id 3B13FAC908; Mon, 4 Jan 2016 01:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2015; t=1451898668; bh=xK/JFgpB6GjEP0bfLOfA82gd7Cc=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=setqhAqjkvtn9f67jXnTlJrp/4/25/0R66rwpqM9meLUuTlV4fj7NxL+KgU19gOeE N7Oe88zuWght9Daka8W6gsvjdMiA4B3b37yIu96XR6yBBC+sv1WIfa428d9GquAcD5 xedeSX8sLfgrTVuF5dkKcIZk1OPyC+skN2XqPjDk=qPjDk= Comments: QMDA 0.3 Received: (qmail 50655 invoked by uid 1001); 4 Jan 2016 09:11:08 -0000 Date: 4 Jan 2016 09:11:08 +0000 Message-ID: <20160104091108.50654.qmail@f5-external.bushwire.net> From: "Mark Delany" To: freebsd-net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? References: <1451841004.10139.34.camel@me.com> <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160104085415.GS3625@kib.kiev.ua> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 09:11:09 -0000 On 04Jan16, Konstantin Belousov allegedly wrote: > On Sun, Jan 03, 2016 at 09:47:20PM +0000, Mark Delany wrote: > > Eg, if a signal arrives after > > more than zero packets have been processed by recvmmsg() what is the > > correct return value? -1 or the count of messages returned? > > This is really not a question to consider different answers. Unix > already made a (right, IMO) decision there, e.g. for read(2) syscall. > If any data was actually read, the length of the consumed data must be > returned, and not the error. So the error is lost? In that case, recvmmsg() is not the same as an iteration over recvmsg(). Besides, a signal isn't necessarily an error. Think SIGALRM. The point is that recvmmsg() may have populated the struct mmsghdr* with a number of inbound messages then it is interrupted by a signal. It then has a choice of telling user space that it has 'n' messages to be processed or -1/EINTR that a signal occurred. If the choice is the former, then the signal is lost. If the choice is the latter then 'n' messages are lost. There is no return possible which indicates that there are messages *and* a signal. Thinking out loud here: are there any other "batch" system calls like recvmmsg() that can offer guidance? Mark. From owner-freebsd-net@freebsd.org Mon Jan 4 09:39:05 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67D86A61C08 for ; Mon, 4 Jan 2016 09:39:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01DEF1CFB for ; Mon, 4 Jan 2016 09:39:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u049d0ls020445 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 4 Jan 2016 11:39:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u049d0ls020445 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u049cxQx020443; Mon, 4 Jan 2016 11:38:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 4 Jan 2016 11:38:59 +0200 From: Konstantin Belousov To: Mark Delany Cc: freebsd-net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160104093859.GV3625@kib.kiev.ua> References: <1451841004.10139.34.camel@me.com> <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <20160104091108.50654.qmail@f5-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160104091108.50654.qmail@f5-external.bushwire.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 09:39:05 -0000 On Mon, Jan 04, 2016 at 09:11:08AM +0000, Mark Delany wrote: > On 04Jan16, Konstantin Belousov allegedly wrote: > > On Sun, Jan 03, 2016 at 09:47:20PM +0000, Mark Delany wrote: > > > Eg, if a signal arrives after > > > more than zero packets have been processed by recvmmsg() what is the > > > correct return value? -1 or the count of messages returned? > > > > This is really not a question to consider different answers. Unix > > already made a (right, IMO) decision there, e.g. for read(2) syscall. > > If any data was actually read, the length of the consumed data must be > > returned, and not the error. > > So the error is lost? In that case, recvmmsg() is not the same as an > iteration over recvmsg(). > > Besides, a signal isn't necessarily an error. Think SIGALRM. The signal is the signal, it is not an error in any imaginable sense. > > The point is that recvmmsg() may have populated the struct mmsghdr* > with a number of inbound messages then it is interrupted by a signal. > > It then has a choice of telling user space that it has 'n' messages to > be processed or -1/EINTR that a signal occurred. > > If the choice is the former, then the signal is lost. If the choice is > the latter then 'n' messages are lost. There is no return possible > which indicates that there are messages *and* a signal. Why is a signal lost in the scenario you described ? Signal interrupted the sleep, which is the only required interaction between a signal delivery and slow syscalls. EINTR (or ERESTART) is the placeholder for syscalls to return something when there is no reasonable return value otherwise. E.g. read(2) without any data already accepted needs to return EINTR and not 0, to not confuse apps with ^D or EOF. But this is _not_ the mechanism used to deliver signals. > > Thinking out loud here: are there any other "batch" system calls like > recvmmsg() that can offer guidance? You stripped the part of my message which give you the example: read(2) (on slow devices and sockets). From owner-freebsd-net@freebsd.org Mon Jan 4 09:59:10 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17BB1A6038D for ; Mon, 4 Jan 2016 09:59:10 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.rbsd.freebsd.org (unknown [IPv6:2607:fc50:2000:101::1bb:73]) by mx1.freebsd.org (Postfix) with ESMTP id 0353C123A for ; Mon, 4 Jan 2016 09:59:10 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.rbsd.freebsd.org (Postfix, from userid 1346) id F3DB1331E2DE; Mon, 4 Jan 2016 09:59:09 +0000 (UTC) Date: Mon, 4 Jan 2016 09:59:09 +0000 To: freebsd-net@freebsd.org From: "nvass-gmx.com (Nikos Vassiliadis)" Reply-to: D1944+325+8925873bdc96dfc2@reviews.freebsd.org Subject: [Differential] [Commented On] D1944: PF and VIMAGE fixes Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: <568A4231.2040405@gmx.com> References: <568A4231.2040405@gmx.com> Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFaKQm0= MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 09:59:10 -0000 nvass-gmx.com added a comment. Sure, I will take a look REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, trociny, kristof, gnn, zec, rodrigc, glebius, eri Cc: mmoll, javier_ovi_yahoo.com, farrokhi, julian, robak, freebsd-virtualization-list, freebsd-pf-list, freebsd-net-list From owner-freebsd-net@freebsd.org Mon Jan 4 10:17:54 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1DB6A60AA9 for ; Mon, 4 Jan 2016 10:17:54 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: from f5.bushwire.net (f5.bushwire.net [IPv6:2607:fc50:1000:5b00::2]) by mx1.freebsd.org (Postfix) with ESMTP id D8A10128F for ; Mon, 4 Jan 2016 10:17:54 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: by f5.bushwire.net (Postfix, from userid 1001) id EF645AC908; Mon, 4 Jan 2016 02:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2015; t=1451902667; bh=gKw6zpszs2hIVvjBheQb2A2TyDI=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=V0/I1aEj6SFFDacgnss292EPBRxHOGeXA8vaEV6/LwxnPJb9/U3AQ5uwxoAhTYLTY mtkGbiPWYOqluxHa6y+++mwuqclEhq/aAzwNrLC7B4fLHvLjvBi6t3DiVMZsCZXXeL AbPjJ74aHXSuTjRQTyUiNrwj5mSecb7cc64GqMos=GqMos= Comments: QMDA 0.3 Received: (qmail 58348 invoked by uid 1001); 4 Jan 2016 10:17:47 -0000 Date: 4 Jan 2016 10:17:47 +0000 Message-ID: <20160104101747.58347.qmail@f5-external.bushwire.net> From: "Mark Delany" To: freebsd-net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? References: <1451841004.10139.34.camel@me.com> <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160104093859.GV3625@kib.kiev.ua> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 10:17:55 -0000 > Why is a signal lost in the scenario you described ? Because the return can only indicate a signal/error *or* a batch of messages but not both and the semantics of recvmsg() means that both could occur. Don't just consider signals, consider any -1/errno return from recvmsg() such as -1/EAGAIN or -1/ENOBUFS or -1/EFAULT. If one emulates recvmmsg() via multiple calls to recvmsg() and the emulation receives 'n' messages via recvmsg() then gets a -1/EFAULT return on message 'n'+1 then what does it return to the caller? If it returns 'n' messages then the EFAULT is lost. If it returns -1/EFAULT then the 'n' messages are lost. Mark. From owner-freebsd-net@freebsd.org Mon Jan 4 15:42:20 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 983DFA61DC5 for ; Mon, 4 Jan 2016 15:42:20 +0000 (UTC) (envelope-from mailhuanhuan@gmail.com) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 6F5A51828; Mon, 4 Jan 2016 15:42:20 +0000 (UTC) (envelope-from mailhuanhuan@gmail.com) Received: by mail-pf0-x22a.google.com with SMTP id 65so158911798pff.3; Mon, 04 Jan 2016 07:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; bh=0wS4rJXcbQ6fvFEdd5PV00fpvpqdMFWjc+xP7ThqQIA=; b=ciOjrcmtGKmMcZOVDZz8xbr1Z+mvZlmT39bsOSrkhAbeVsgfTfKOtmxAVLyl1LHj/t +AFM4LwZR3h7wg8dy05GF5aJVrR2B6GTQUENzOF5Hi62QeFA2cn5zc79Z935zUZwadIT ggQqhb28zC/Qqqd2AbzjIlSRKNGE3tmHdofdsovs7CQpsQmsYNhikpOhT5gsPHD9IZwW ZW7dPxdJ6C9z8XvAG7VSd7AbWA+OF1ZhluZYxZnXfBIsKhiwqMzfCXQz4mOFvznip9CB dVozGcNfrMiqY/IHAGjH0m220QMRINFHlICcdJw32Rn+7el9gHw5mLP/J8MZsd2WNPNj ZtGg== X-Received: by 10.98.7.92 with SMTP id b89mr126951411pfd.69.1451922140002; Mon, 04 Jan 2016 07:42:20 -0800 (PST) Received: from [192.168.255.2] ([104.207.154.124]) by smtp.gmail.com with ESMTPSA id f67sm79404763pfd.10.2016.01.04.07.42.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jan 2016 07:42:19 -0800 (PST) From: HuanHuan X-Google-Original-From: HuanHuan Date: Mon, 4 Jan 2016 23:41:35 +0800 (CST) To: Julian Elischer cc: HuanHuan , Rui Paulo , freebsd-net@freebsd.org, Luigi Rizzo Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <568A0FC6.8050107@freebsd.org> Message-ID: References: <1451841004.10139.34.camel@me.com> <568A0FC6.8050107@freebsd.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 15:42:20 -0000 Thank you for pointing out that. I will try to rewrite some (if I could), like the the ASCII path that received. (It may reduce some time or not? But just try....) On Mon, 4 Jan 2016, Julian Elischer wrote: > On 4/01/2016 5:32 AM, HuanHuan wrote: >> Hi Rui, >> >> There are no existing applications, but these two calls are for developing >> new application on 10G links. >> >> Currently I use netgraph, especially ng_socket node. And a simple >> recvfrom() on a ng_socket costs ~5us or so (200K per second). And there are >> many netgraph sockets. So it's good to reduce the time by ultilizing >> send/recvmmsg() if there are these two syscalls. Even a simple-loop like >> implmentation like linux's will be good as Luigi has suggested. > > As the writer of netgraph I would like to point out that it was never > designed to be a high throughput service. > I'm happy thought that it CAN be used at these speeds but I designed it for > prototyping and for serial line speeds. > The idea was that once something was prototyped out, one would take the code > from all the modules used and create > a special purpose module that dd what you need. > The fact that people have not needed the last step is gratifying but > surprising. > >> >> On Sun, 3 Jan 2016, Rui Paulo wrote: >> >>> On Sun, 2016-01-03 at 18:34 +0800, HuanHuan wrote: >>>> NetBSD 7.0 has just introduced these two syscalls. >>>> And Linux also has them. >>>> >>>> Does FreeBSD have them? Or plan to support them in the future? >>> >>> FreeBSD does not have them. It doesn't seem especially hard to >>> implement, though. Do you know any major application already using >>> them? >>> >>> -- >>> Rui Paulo >>> >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > > From owner-freebsd-net@freebsd.org Mon Jan 4 19:40:51 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8369EA619D9 for ; Mon, 4 Jan 2016 19:40:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01C941C1C for ; Mon, 4 Jan 2016 19:40:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u04JejpY078017 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 4 Jan 2016 21:40:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u04JejpY078017 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u04JeiU3077986; Mon, 4 Jan 2016 21:40:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 4 Jan 2016 21:40:44 +0200 From: Konstantin Belousov To: Mark Delany Cc: freebsd-net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160104194044.GD3625@kib.kiev.ua> References: <1451841004.10139.34.camel@me.com> <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160104101747.58347.qmail@f5-external.bushwire.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 19:40:51 -0000 On Mon, Jan 04, 2016 at 10:17:47AM +0000, Mark Delany wrote: > > Why is a signal lost in the scenario you described ? > > Because the return can only indicate a signal/error *or* a batch of > messages but not both and the semantics of recvmsg() means that both > could occur. > > Don't just consider signals, consider any -1/errno return from > recvmsg() such as -1/EAGAIN or -1/ENOBUFS or -1/EFAULT. > > If one emulates recvmmsg() via multiple calls to recvmsg() and the > emulation receives 'n' messages via recvmsg() then gets a -1/EFAULT > return on message 'n'+1 then what does it return to the caller? > > If it returns 'n' messages then the EFAULT is lost. > > If it returns -1/EFAULT then the 'n' messages are lost. You just repeat arguments for the text in my messages, which you removed on reply. Of course, it is unacceptable to loose the received data. Of course, the EFAULT or other similar error would be encountered on the next call. If it is not encountered because user passed other buffer, it is even better. If the issue is with the socket state itself, then the error will be reported on next call, as it is done for all other socket functions. This is how the system works already. From owner-freebsd-net@freebsd.org Mon Jan 4 21:06:46 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A995A619E5 for ; Mon, 4 Jan 2016 21:06:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0811F1C93 for ; Mon, 4 Jan 2016 21:06:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u04L6g8B068877 for ; Mon, 4 Jan 2016 21:06:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194515] Fatal Trap 12 Kernel with vimage Date: Mon, 04 Jan 2016 21:06:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:06:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194515 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 058 | |73 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jan 4 21:07:42 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5B15A61AF8 for ; Mon, 4 Jan 2016 21:07:42 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: from f5.bushwire.net (f5.bushwire.net [IPv6:2607:fc50:1000:5b00::2]) by mx1.freebsd.org (Postfix) with ESMTP id AAC5A1F38 for ; Mon, 4 Jan 2016 21:07:42 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: by f5.bushwire.net (Postfix, from userid 1001) id 0DDA1AC908; Mon, 4 Jan 2016 13:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2015; t=1451941662; bh=54SAH3F8NmRWlyfuztMR02UebqE=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=rRoTC7vE2Ps30PKTmJxUPTCDl0ra3mT5w0j/jukT/HQ1AqJg8NdY5pjnJQOi4/qU6 ZGARJ1gkJwrRgsgkdGGxgpNf6TEAeMlw0gPRZD7Y3O4+bE3arNYr0pIRh/JyOPAA1I +2SDSU1ze8fN2GrV+50po4yHGwcTRP9VqVV2uQTk=2uQTk= Comments: QMDA 0.3 Received: (qmail 32813 invoked by uid 1001); 4 Jan 2016 21:07:41 -0000 Date: 4 Jan 2016 21:07:41 +0000 Message-ID: <20160104210741.32812.qmail@f5-external.bushwire.net> From: "Mark Delany" To: freebsd-net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? References: <1451841004.10139.34.camel@me.com> <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160104194044.GD3625@kib.kiev.ua> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:07:42 -0000 > You just repeat arguments for the text in my messages, which you removed > on reply. My goal is to get you to scruitinize. Thank you for helping. Mark. From owner-freebsd-net@freebsd.org Mon Jan 4 21:18:22 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63E69A61FDC for ; Mon, 4 Jan 2016 21:18:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 546131A7C for ; Mon, 4 Jan 2016 21:18:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u04LIL99025497 for ; Mon, 4 Jan 2016 21:18:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 201694] 10.2-BETA2 crashing when killing VIMAGE/VNET jails Date: Mon, 04 Jan 2016 21:18:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: crash, needs-qa, vimage X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bz@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:18:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D201694 Bjoern A. Zeeb changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |vimage --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Jan 5 21:59:22 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69EFAA63644 for ; Tue, 5 Jan 2016 21:59:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59B1E18D5 for ; Tue, 5 Jan 2016 21:59:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u05LxLM4036020 for ; Tue, 5 Jan 2016 21:59:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202983] ixv driver in 11.0-CURRENT(10.1 & 10.2 RELEASE) doesn't pass traffic using XEN hypervisor(AWS EC2) Date: Tue, 05 Jan 2016 21:59:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jlpetz@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 05 Jan 2016 21:59:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D202983 --- Comment #5 from Jarrod Petz --- I didn't see any action from other on this, so have submitted a diff for review. https://reviews.freebsd.org/D4788 This allows DHCP to work and obtain a lease. Be mindful though that if you = use this that you should ensure the MTU is set correctly for AWS instances. See= my diff for details on why. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 6 00:08:21 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08ED1A63FA9 for ; Wed, 6 Jan 2016 00:08:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED49A17F8 for ; Wed, 6 Jan 2016 00:08:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0608KJ6030214 for ; Wed, 6 Jan 2016 00:08:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205706] Watchdog timeout on em driver under heavy traffic on a bridge configuration Date: Wed, 06 Jan 2016 00:08:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: avilamarquezalvaro2015@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 00:08:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205706 --- Comment #1 from avilamarquezalvaro2015@gmail.com --- Errata for comment #1: Where it reads 10.2-CURRENT must be 10.2-RELEASE --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 6 15:12:38 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5D27A64C4D for ; Wed, 6 Jan 2016 15:12:38 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.rbsd.freebsd.org (unknown [IPv6:2607:fc50:2000:101::1bb:73]) by mx1.freebsd.org (Postfix) with ESMTP id A258F1442 for ; Wed, 6 Jan 2016 15:12:38 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.rbsd.freebsd.org (Postfix, from userid 1346) id 9F4CF331EDA8; Wed, 6 Jan 2016 15:12:38 +0000 (UTC) Date: Wed, 6 Jan 2016 15:12:38 +0000 To: freebsd-net@freebsd.org From: "lakshmi.n_msystechnologies.com (LN)" Reply-to: D1986+325+381818416dc12ca2@reviews.freebsd.org Subject: [Differential] [Commented On] D1986: Teach lagg(4) to change MTU Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D1986: Teach lagg(4) to change MTU X-Herald-Rules: none, <28> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ODZhMzNlYThiYzMxOTgzYmRhMDE5M2Q2Yzk4IFaNLuY= MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 15:12:38 -0000 lakshmi.n_msystechnologies.com added a comment. Thanks @smh, @melifaro and @hrs for the review comments. REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D1986 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: rpokala, rstone, rpokala-panasas.com Cc: smh, imp, melifaro, hrs, sbruno, lakshmi.n_msystechnologies.com, emaste, ae, freebsd-net-list From owner-freebsd-net@freebsd.org Wed Jan 6 18:00:22 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B9D3A64DCE for ; Wed, 6 Jan 2016 18:00:22 +0000 (UTC) (envelope-from dchagin@chd.heemeyer.club) Received: from heemeyer.club (heemeyer.club [108.61.204.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "heemeyer.club", Issuer "heemeyer.club" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B0E21E19 for ; Wed, 6 Jan 2016 18:00:21 +0000 (UTC) (envelope-from dchagin@chd.heemeyer.club) Received: from chd.heemeyer.club ([78.107.232.239]) by heemeyer.club (8.15.2/8.15.1) with ESMTPS id u06I09wo018565 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 6 Jan 2016 18:00:12 GMT (envelope-from dchagin@chd.heemeyer.club) X-Authentication-Warning: heemeyer.club: Host [78.107.232.239] claimed to be chd.heemeyer.club Received: from chd.heemeyer.club (localhost [127.0.0.1]) by chd.heemeyer.club (8.15.2/8.15.1) with ESMTPS id u06I09rC001398 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 6 Jan 2016 21:00:09 +0300 (MSK) (envelope-from dchagin@chd.heemeyer.club) Received: (from dchagin@localhost) by chd.heemeyer.club (8.15.2/8.15.1/Submit) id u06I09kB001397 for freebsd-net@freebsd.org; Wed, 6 Jan 2016 21:00:09 +0300 (MSK) (envelope-from dchagin) Date: Wed, 6 Jan 2016 21:00:08 +0300 From: Chagin Dmitry To: freebsd-net@freebsd.org Subject: long network segment call stack can fail Message-ID: <20160106180008.GA1363@chd.heemeyer.club> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:00:22 -0000 Hi, all. Here's a panic that occurs during the massive network loads, as far as I can see network segment has eaten the whole stack, so only 0xeb0 bytes left for interrupt hanlder. #0 doadump (textdump=0x8151cd90) at /home/git/head/sys/kern/kern_shutdown.c:296 #1 0xffffffff803d4715 in db_fncall_generic (addr=0xffffffff80763f00, rv=0xffffffff8151cd60 , nargs=0x0, args=0xffffffff8151cd70 ) at /home/git/head/sys/ddb/db_command.c:568 #2 0xffffffff803d3e94 in db_fncall (dummy1=0xffffffff8151cea0, dummy2=0x0, dummy3=0x0, dummy4=0xffffffff8151cea0 "\n") at /home/git/head/sys/ddb/db_command.c:616 #3 0xffffffff803d371e in db_command (last_cmdp=0xffffffff812e3838 , cmd_table=0x0, dopager=0x1) at /home/git/head/sys/ddb/db_command.c:440 #4 0xffffffff803d32be in db_command_loop () at /home/git/head/sys/ddb/db_command.c:493 #5 0xffffffff803d7b53 in db_trap (type=0x3, code=0x0) at /home/git/head/sys/ddb/db_main.c:251 #6 0xffffffff807c568f in kdb_trap (type=0x3, code=0x0, tf=0xffffffff8151d430 ) at /home/git/head/sys/kern/subr_kdb.c:654 #7 0xffffffff80c7a9f1 in trap (frame=0xffffffff8151d430 ) at /home/git/head/sys/amd64/amd64/trap.c:549 #8 0xffffffff80c7bb5a in trap_check (frame=0xffffffff8151d430 ) at /home/git/head/sys/amd64/amd64/trap.c:628 #9 0xffffffff80c53f47 in calltrap () at /home/git/head/sys/amd64/amd64/exception.S:234 #10 0xffffffff807c4ee5 in breakpoint () at ./machine/cpufunc.h:63 #11 0xffffffff807c4ae7 in kdb_enter (why=0xffffffff80db94e3 "panic", msg=0xffffffff80db94e3 "panic") at /home/git/head/sys/kern/subr_kdb.c:443 #12 0xffffffff8076461b in vpanic (fmt=0xffffffff80e1067f "double fault", ap=0xffffffff8151d630 ) at /home/git/head/sys/kern/kern_shutdown.c:750 #13 0xffffffff807646c0 in panic (fmt=0xffffffff80e1067f "double fault") at /home/git/head/sys/kern/kern_shutdown.c:688 #14 0xffffffff80c7bc6a in dblfault_handler (frame=0xffffffff8151d6b0 ) at /home/git/head/sys/amd64/amd64/trap.c:861 #15 0xffffffff80c5403c in Xdblfault () at /home/git/head/sys/amd64/amd64/exception.S:290 #16 0xffffffff807a26c5 in cpu_search (cg=0xffffffff8146b148 , low=0xfffffe02d858b298, high=0x0, match=0x1) at /home/git/head/sys/kern/sched_ule.c:689 #17 cpu_search_lowest (cg=0xffffffff8146b148 , low=0xfffffe02d858b298) at /home/git/head/sys/kern/sched_ule.c:781 #18 0xffffffff807a286b in cpu_search (cg=0xffffffff8146b068 , low=0xfffffe02d858b418, high=0x0, match=0x1) at /home/git/head/sys/kern/sched_ule.c:708 #19 cpu_search_lowest (cg=0xffffffff8146b068 , low=0xfffffe02d858b418) at /home/git/head/sys/kern/sched_ule.c:781 #20 0xffffffff807a286b in cpu_search (cg=0xffffffff8146b030 , low=0xfffffe02d858b490, high=0x0, match=0x1) at /home/git/head/sys/kern/sched_ule.c:708 #21 cpu_search_lowest (cg=0xffffffff8146b030 , low=0xfffffe02d858b490) at /home/git/head/sys/kern/sched_ule.c:781 #22 0xffffffff807a9496 in sched_lowest (cg=0xffffffff8146b030 , mask=..., pri=0x78, maxload=0x7fffffff, prefer=0x0) at /home/git/head/sys/kern/sched_ule.c:813 #23 0xffffffff807a511b in sched_pickcpu (td=0xfffff8000bb3a4f0, flags=0x0) at /home/git/head/sys/kern/sched_ule.c:1290 #24 0xffffffff807a61c8 in sched_add (td=0xfffff8000bb3a4f0, flags=0x0) at /home/git/head/sys/kern/sched_ule.c:2426 #25 0xffffffff807a5e78 in sched_wakeup (td=0xfffff8000bb3a4f0) at /home/git/head/sys/kern/sched_ule.c:2058 #26 0xffffffff80777eb4 in setrunnable (td=0xfffff8000bb3a4f0) at /home/git/head/sys/kern/kern_synch.c:522 #27 0xffffffff807dcf99 in sleepq_resume_thread (sq=0xfffff800036fb680, td=0xfffff8000bb3a4f0, pri=0x0) at /home/git/head/sys/kern/subr_sleepqueue.c:776 #28 0xffffffff807db303 in sleepq_timeout (arg=0xfffff8000bb3a4f0) at /home/git/head/sys/kern/subr_sleepqueue.c:915 #29 0xffffffff8078bfac in softclock_call_cc (c=0xfffff8000bb3a8a8, cc=0xffffffff81589180 , direct=0x1) at /home/git/head/sys/kern/kern_timeout.c:723 #30 0xffffffff8078b78a in callout_process (now=0x393bab69d8fb) at /home/git/head/sys/kern/kern_timeout.c:493 #31 0xffffffff80cc8932 in handleevents (now=0x393bab69d8fb, fake=0x0) at /home/git/head/sys/kern/kern_clocksource.c:212 #32 0xffffffff80cc941c in timercb (et=0xffffffff81562d98 , arg=0x0) at /home/git/head/sys/kern/kern_clocksource.c:345 #33 0xffffffff80d1e9e8 in lapic_handle_timer (frame=0xfffffe02d858bdf0) at /home/git/head/sys/x86/x86/local_apic.c:1056 #34 0xffffffff80c54b3c in Xtimerint () at /home/git/head/sys/amd64/amd64/apic_vector.S:133 #35 0xffffffff80c0cc36 in uma_dbg_getslab (zone=0xfffff80003e15000, item=0xfffff801f0e4b800) at /home/git/head/sys/vm/uma_dbg.c:219 #36 0xffffffff80c0ca34 in uma_dbg_alloc (zone=0xfffff80003e15000, slab=0x0, item=0xfffff801f0e4b800) at /home/git/head/sys/vm/uma_dbg.c:242 #37 0xffffffff80c04e58 in uma_zalloc_arg (zone=0xfffff80003e15000, udata=0xfffffe02d858c070, flags=0x1) at /home/git/head/sys/vm/uma_core.c:2220 #38 0xffffffff8095ea38 in m_gethdr (how=0x1, type=0x1) at /home/git/head/sys/sys/mbuf.h:672 #39 0xffffffff8095e8b6 in ieee80211_mbuf_adjust (vap=0xfffff8000f2b1000, hdrsize=0x1a, key=0xfffffe0001817138, m=0xfffff8000f744400) at /home/git/head/sys/net80211/ieee80211_output.c:1113 #40 0xffffffff8095add2 in ieee80211_encap (vap=0xfffff8000f2b1000, ni=0xfffffe0001817000, m=0xfffff8000f744400) at /home/git/head/sys/net80211/ieee80211_output.c:1354 #41 0xffffffff8095a234 in ieee80211_vap_pkt_send_dest (vap=0xfffff8000f2b1000, m=0xfffff8000f744400, ni=0xfffffe0001817000) at /home/git/head/sys/net80211/ieee80211_output.c:258 #42 0xffffffff8095c91e in ieee80211_start_pkt (vap=0xfffff8000f2b1000, m=0xfffff8000f744400) at /home/git/head/sys/net80211/ieee80211_output.c:426 #43 0xffffffff8095c27b in ieee80211_vap_transmit (ifp=0xfffff8000f2b7000, m=0xfffff8000f744400) at /home/git/head/sys/net80211/ieee80211_output.c:486 #44 0xffffffff808db57b in bridge_enqueue (sc=0xfffff8000f2c5c00, dst_ifp=0xfffff8000f2b7000, m=0xfffff8000f744400) at /home/git/head/sys/net/if_bridge.c:1919 #45 0xffffffff808e02be in bridge_output (ifp=0xfffff8000f2b7000, m=0xfffff8000f744400, sa=0x0, rt=0x0) at /home/git/head/sys/net/if_bridge.c:2085 #46 0xffffffff808e4b52 in ether_output (ifp=0xfffff8000f2b7000, m=0xfffff8000f744400, dst=0xfffff8000befe6b0, ro=0xfffffe02d858d248) at /home/git/head/sys/net/if_ethersubr.c:376 #47 0xffffffff8095cab7 in ieee80211_output (ifp=0xfffff8000f2b7000, m=0xfffff8000f744400, dst=0xfffff8000befe6b0, ro=0xfffffe02d858d248) at /home/git/head/sys/net80211/ieee80211_output.c:576 #48 0xffffffff809fd851 in ip_output (m=0xfffff8000f744400, opt=0x0, ro=0xfffffe02d858d248, flags=0x0, imo=0x0, inp=0xfffff801f786c7d0) at /home/git/head/sys/netinet/ip_output.c:638 #49 0xffffffff80ade593 in tcp_output (tp=0xfffff8016b2bc418) at /home/git/head/sys/netinet/tcp_output.c:1414 #50 0xffffffff80ad59ee in tcp_do_segment (m=0xfffff8000f71d100, th=0xfffff800071f804a, so=0xfffff8016b5c92e8, tp=0xfffff8016b2bc418, drop_hdrlen=0x34, tlen=0x544, iptos=0x0, ti_locked=0x1) at /home/git/head/sys/netinet/tcp_input.c:1904 #51 0xffffffff80ad3c9f in tcp_input (mp=0xfffffe02d858de28, offp=0xfffffe02d858de00, proto=0x6) at /home/git/head/sys/netinet/tcp_input.c:1417 #52 0xffffffff809f8b91 in ip_input (m=0x0) at /home/git/head/sys/netinet/ip_input.c:786 #53 0xffffffff808f6b4e in netisr_dispatch_src (proto=0x1, source=0x0, m=0xfffff8000f71d100) at /home/git/head/sys/net/netisr.c:972 #54 0xffffffff808f7157 in netisr_dispatch (proto=0x1, m=0xfffff8000f71d100) at /home/git/head/sys/net/netisr.c:1063 #55 0xffffffff808e55b0 in ether_demux (ifp=0xfffff8000f2b7000, m=0xfffff8000f71d100) at /home/git/head/sys/net/if_ethersubr.c:805 #56 0xffffffff808e7231 in ether_input_internal (ifp=0xfffff8000f2b7000, m=0xfffff8000f71d100) at /home/git/head/sys/net/if_ethersubr.c:611 #57 0xffffffff808e6a3f in ether_nh_input (m=0xfffff8000f71d100) at /home/git/head/sys/net/if_ethersubr.c:641 #58 0xffffffff808f6b4e in netisr_dispatch_src (proto=0x5, source=0x0, m=0xfffff8000f71d100) at /home/git/head/sys/net/netisr.c:972 #59 0xffffffff808f7157 in netisr_dispatch (proto=0x5, m=0xfffff8000f71d100) at /home/git/head/sys/net/netisr.c:1063 #60 0xffffffff808e5b6c in ether_input (ifp=0xfffff8000f2b7000, m=0xfffff8000f71d100) at /home/git/head/sys/net/if_ethersubr.c:715 #61 0xffffffff80938d6a in ieee80211_deliver_data (vap=0xfffff8000f2b1000, ni=0xfffffe0001817000, m=0xfffff8000f71d100) at /home/git/head/sys/net80211/ieee80211_input.c:298 #62 0xffffffff80974e77 in sta_input (ni=0xfffffe0001817000, m=0xfffff8000f71d100, rxs=0xfffffe02d858e440, rssi=0x82, nf=0xb0) at /home/git/head/sys/net80211/ieee80211_sta.c:868 #63 0xffffffff809383b8 in ieee80211_input_mimo (ni=0xfffffe0001817000, m=0xfffff8000f71d100, rx=0xfffffe02d858e560) at /home/git/head/sys/net80211/ieee80211_input.c:103 #64 0xffffffff804c158f in iwm_mvm_rx_rx_mpdu (sc=0xfffffe000108f000, pkt=0xfffff800071f8000, data=0xfffffe00010ce928) at /home/git/head/sys/dev/iwm/if_iwm.c:2391 #65 0xffffffff804bfe88 in iwm_notif_intr (sc=0xfffffe000108f000) at /home/git/head/sys/dev/iwm/if_iwm.c:4092 #66 0xffffffff804bf55e in iwm_intr (arg=0xfffffe000108f000) at /home/git/head/sys/dev/iwm/if_iwm.c:4416 #67 0xffffffff8070f7c8 in intr_event_execute_handlers (p=0xfffff80003df7aa0, ie=0xfffff80003def900) at /home/git/head/sys/kern/kern_intr.c:1262 #68 0xffffffff807105b7 in ithread_execute_handlers (p=0xfffff80003df7aa0, ie=0xfffff80003def900) at /home/git/head/sys/kern/kern_intr.c:1275 #69 0xffffffff807103e6 in ithread_loop (arg=0xfffff80007002500) at /home/git/head/sys/kern/kern_intr.c:1356 #70 0xffffffff8070ad89 in fork_exit (callout=0xffffffff80710270 , arg=0xfffff80007002500, frame=0xfffffe02d858eac0) at /home/git/head/sys/kern/kern_fork.c:1010 #71 0xffffffff80c5447e in fork_trampoline () at /home/git/head/sys/amd64/amd64/exception.S:609 #71 0xffffffff80c5447e in fork_trampoline () at /home/git/head/sys/amd64/amd64/exception.S:609 up 71 609 call fork_exit print $sp $1 = (void *) 0xfffffe02d858eac0 up 35 #35 0xffffffff80c0cc36 in uma_dbg_getslab (zone=0xfffff80003e15000, item=0xfffff801f0e4b800) at /home/git/head/sys/vm/uma_dbg.c:219 219 if (keg->uk_flags & UMA_ZONE_HASH) print $sp $37 = (void *) 0xfffffe02d858beb0 so, 0x0eb0 bytes left on stack before fault at 0xfffffe02d858b000 up 16 #16 0xffffffff807a26c5 in cpu_search (cg=0xffffffff8146b148 , low=0xfffffe02d858b298, high=0x0, match=0x1) at /home/git/head/sys/kern/sched_ule.c:689 689 cpu = CPU_FFS(&cpumask) - 1; print $sp $56 = (void *) 0xfffffe02d858b000 From owner-freebsd-net@freebsd.org Wed Jan 6 20:28:17 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80D64A6655D for ; Wed, 6 Jan 2016 20:28:17 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DB4414E6; Wed, 6 Jan 2016 20:28:16 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.9/8.14.9) with ESMTP id u06KCeWG054234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Jan 2016 21:12:40 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: dchagin@freebsd.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id u06KCZoK015395 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Jan 2016 03:12:35 +0700 (KRAT) (envelope-from eugen@grosbein.net) Subject: Re: long network segment call stack can fail To: Chagin Dmitry , freebsd-net@freebsd.org References: <20160106180008.GA1363@chd.heemeyer.club> From: Eugene Grosbein Message-ID: <568D752D.8090304@grosbein.net> Date: Thu, 7 Jan 2016 03:12:29 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160106180008.GA1363@chd.heemeyer.club> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 20:28:17 -0000 07.01.2016 1:00, Chagin Dmitry пишет: > Hi, all. > > Here's a panic that occurs during the massive network loads, > as far as I can see network segment has eaten the whole stack, so > only 0xeb0 bytes left for interrupt hanlder. For stable/10, sys/amd64/include/param.h defines KSTACK_PAGES=4 as default and GENERIC does not redefine it but NOTES gives example of increase upto 5. You could increase kernel thread size that way or switch to sysctl net.isr.dispatch=deferred so that input path just enqueues new frame and returns, freeing stack. Netisr kernel thread will take care of it later. Eugene Grosbein From owner-freebsd-net@freebsd.org Wed Jan 6 20:50:53 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77C44A66DDE for ; Wed, 6 Jan 2016 20:50:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 4B214194F; Wed, 6 Jan 2016 20:50:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x22f.google.com with SMTP id ik10so40548656igb.1; Wed, 06 Jan 2016 12:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ceKy5t2gyhkMrcIC1sAieJNzIoMSFXuiKf5V6rWkJTc=; b=z4fsJ+Nt4/gfEXkHNFf8s3xcpPGEPnbuKmOlzAKP851uUJeG0WHvgIsP1YURIU6JAq GNf5/g0JaaR9HAItdKIPTSB041NI5xXe0uCVhNZi38r1Hl957S1R1evcJotzcLm7Rq3l RURq7xV7r0L/oAF8FRfihdB43KNVCwqeiDVyRw1im7xwfd0MUnugqjLsYKUdGUeD9JZz QiM59JClg7GXV00wkJC6JfWdFXMX0Uyky7trF/FO/6ShPbivMlaiApccfBVBLA0qv+4+ 9BoXvFIea5bh6+NnbeV9e9pB2VQTdCEIIGueaX/12xJ5Gd0i4v+T72Bgh1pWMAsn8Jkc jAiA== MIME-Version: 1.0 X-Received: by 10.50.143.39 with SMTP id sb7mr2769017igb.37.1452113452831; Wed, 06 Jan 2016 12:50:52 -0800 (PST) Received: by 10.36.121.202 with HTTP; Wed, 6 Jan 2016 12:50:52 -0800 (PST) In-Reply-To: <20160106180008.GA1363@chd.heemeyer.club> References: <20160106180008.GA1363@chd.heemeyer.club> Date: Wed, 6 Jan 2016 12:50:52 -0800 Message-ID: Subject: Re: long network segment call stack can fail From: Adrian Chadd To: Chagin Dmitry Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 20:50:53 -0000 hah, that's very pretty. The downside of a completely direct-dispatch network stack. :) -a On 6 January 2016 at 10:00, Chagin Dmitry wrote: > Hi, all. > > Here's a panic that occurs during the massive network loads, > as far as I can see network segment has eaten the whole stack, so > only 0xeb0 bytes left for interrupt hanlder. > > > #0 doadump (textdump=0x8151cd90) at /home/git/head/sys/kern/kern_shutdown.c:296 > #1 0xffffffff803d4715 in db_fncall_generic (addr=0xffffffff80763f00, rv=0xffffffff8151cd60 , > nargs=0x0, args=0xffffffff8151cd70 ) at /home/git/head/sys/ddb/db_command.c:568 > #2 0xffffffff803d3e94 in db_fncall (dummy1=0xffffffff8151cea0, dummy2=0x0, dummy3=0x0, > dummy4=0xffffffff8151cea0 "\n") at /home/git/head/sys/ddb/db_command.c:616 > #3 0xffffffff803d371e in db_command (last_cmdp=0xffffffff812e3838 , cmd_table=0x0, dopager=0x1) > at /home/git/head/sys/ddb/db_command.c:440 > #4 0xffffffff803d32be in db_command_loop () at /home/git/head/sys/ddb/db_command.c:493 > #5 0xffffffff803d7b53 in db_trap (type=0x3, code=0x0) at /home/git/head/sys/ddb/db_main.c:251 > #6 0xffffffff807c568f in kdb_trap (type=0x3, code=0x0, tf=0xffffffff8151d430 ) > at /home/git/head/sys/kern/subr_kdb.c:654 > #7 0xffffffff80c7a9f1 in trap (frame=0xffffffff8151d430 ) > at /home/git/head/sys/amd64/amd64/trap.c:549 > #8 0xffffffff80c7bb5a in trap_check (frame=0xffffffff8151d430 ) > at /home/git/head/sys/amd64/amd64/trap.c:628 > #9 0xffffffff80c53f47 in calltrap () at /home/git/head/sys/amd64/amd64/exception.S:234 > #10 0xffffffff807c4ee5 in breakpoint () at ./machine/cpufunc.h:63 > #11 0xffffffff807c4ae7 in kdb_enter (why=0xffffffff80db94e3 "panic", msg=0xffffffff80db94e3 "panic") > at /home/git/head/sys/kern/subr_kdb.c:443 > #12 0xffffffff8076461b in vpanic (fmt=0xffffffff80e1067f "double fault", ap=0xffffffff8151d630 ) > at /home/git/head/sys/kern/kern_shutdown.c:750 > #13 0xffffffff807646c0 in panic (fmt=0xffffffff80e1067f "double fault") at /home/git/head/sys/kern/kern_shutdown.c:688 > #14 0xffffffff80c7bc6a in dblfault_handler (frame=0xffffffff8151d6b0 ) > at /home/git/head/sys/amd64/amd64/trap.c:861 > #15 0xffffffff80c5403c in Xdblfault () at /home/git/head/sys/amd64/amd64/exception.S:290 > #16 0xffffffff807a26c5 in cpu_search (cg=0xffffffff8146b148 , low=0xfffffe02d858b298, high=0x0, match=0x1) > at /home/git/head/sys/kern/sched_ule.c:689 > #17 cpu_search_lowest (cg=0xffffffff8146b148 , low=0xfffffe02d858b298) > at /home/git/head/sys/kern/sched_ule.c:781 > #18 0xffffffff807a286b in cpu_search (cg=0xffffffff8146b068 , low=0xfffffe02d858b418, high=0x0, match=0x1) > at /home/git/head/sys/kern/sched_ule.c:708 > #19 cpu_search_lowest (cg=0xffffffff8146b068 , low=0xfffffe02d858b418) > at /home/git/head/sys/kern/sched_ule.c:781 > #20 0xffffffff807a286b in cpu_search (cg=0xffffffff8146b030 , low=0xfffffe02d858b490, high=0x0, match=0x1) > at /home/git/head/sys/kern/sched_ule.c:708 > #21 cpu_search_lowest (cg=0xffffffff8146b030 , low=0xfffffe02d858b490) > at /home/git/head/sys/kern/sched_ule.c:781 > #22 0xffffffff807a9496 in sched_lowest (cg=0xffffffff8146b030 , mask=..., pri=0x78, maxload=0x7fffffff, > prefer=0x0) at /home/git/head/sys/kern/sched_ule.c:813 > #23 0xffffffff807a511b in sched_pickcpu (td=0xfffff8000bb3a4f0, flags=0x0) at /home/git/head/sys/kern/sched_ule.c:1290 > #24 0xffffffff807a61c8 in sched_add (td=0xfffff8000bb3a4f0, flags=0x0) at /home/git/head/sys/kern/sched_ule.c:2426 > #25 0xffffffff807a5e78 in sched_wakeup (td=0xfffff8000bb3a4f0) at /home/git/head/sys/kern/sched_ule.c:2058 > #26 0xffffffff80777eb4 in setrunnable (td=0xfffff8000bb3a4f0) at /home/git/head/sys/kern/kern_synch.c:522 > #27 0xffffffff807dcf99 in sleepq_resume_thread (sq=0xfffff800036fb680, td=0xfffff8000bb3a4f0, pri=0x0) > at /home/git/head/sys/kern/subr_sleepqueue.c:776 > #28 0xffffffff807db303 in sleepq_timeout (arg=0xfffff8000bb3a4f0) at /home/git/head/sys/kern/subr_sleepqueue.c:915 > #29 0xffffffff8078bfac in softclock_call_cc (c=0xfffff8000bb3a8a8, cc=0xffffffff81589180 , direct=0x1) > at /home/git/head/sys/kern/kern_timeout.c:723 > #30 0xffffffff8078b78a in callout_process (now=0x393bab69d8fb) at /home/git/head/sys/kern/kern_timeout.c:493 > #31 0xffffffff80cc8932 in handleevents (now=0x393bab69d8fb, fake=0x0) at /home/git/head/sys/kern/kern_clocksource.c:212 > #32 0xffffffff80cc941c in timercb (et=0xffffffff81562d98 , arg=0x0) > at /home/git/head/sys/kern/kern_clocksource.c:345 > #33 0xffffffff80d1e9e8 in lapic_handle_timer (frame=0xfffffe02d858bdf0) at /home/git/head/sys/x86/x86/local_apic.c:1056 > #34 0xffffffff80c54b3c in Xtimerint () at /home/git/head/sys/amd64/amd64/apic_vector.S:133 > #35 0xffffffff80c0cc36 in uma_dbg_getslab (zone=0xfffff80003e15000, item=0xfffff801f0e4b800) > at /home/git/head/sys/vm/uma_dbg.c:219 > #36 0xffffffff80c0ca34 in uma_dbg_alloc (zone=0xfffff80003e15000, slab=0x0, item=0xfffff801f0e4b800) > at /home/git/head/sys/vm/uma_dbg.c:242 > #37 0xffffffff80c04e58 in uma_zalloc_arg (zone=0xfffff80003e15000, udata=0xfffffe02d858c070, flags=0x1) > at /home/git/head/sys/vm/uma_core.c:2220 > #38 0xffffffff8095ea38 in m_gethdr (how=0x1, type=0x1) at /home/git/head/sys/sys/mbuf.h:672 > #39 0xffffffff8095e8b6 in ieee80211_mbuf_adjust (vap=0xfffff8000f2b1000, hdrsize=0x1a, key=0xfffffe0001817138, > m=0xfffff8000f744400) at /home/git/head/sys/net80211/ieee80211_output.c:1113 > #40 0xffffffff8095add2 in ieee80211_encap (vap=0xfffff8000f2b1000, ni=0xfffffe0001817000, m=0xfffff8000f744400) > at /home/git/head/sys/net80211/ieee80211_output.c:1354 > #41 0xffffffff8095a234 in ieee80211_vap_pkt_send_dest (vap=0xfffff8000f2b1000, m=0xfffff8000f744400, > ni=0xfffffe0001817000) at /home/git/head/sys/net80211/ieee80211_output.c:258 > #42 0xffffffff8095c91e in ieee80211_start_pkt (vap=0xfffff8000f2b1000, m=0xfffff8000f744400) > at /home/git/head/sys/net80211/ieee80211_output.c:426 > #43 0xffffffff8095c27b in ieee80211_vap_transmit (ifp=0xfffff8000f2b7000, m=0xfffff8000f744400) > at /home/git/head/sys/net80211/ieee80211_output.c:486 > #44 0xffffffff808db57b in bridge_enqueue (sc=0xfffff8000f2c5c00, dst_ifp=0xfffff8000f2b7000, m=0xfffff8000f744400) > at /home/git/head/sys/net/if_bridge.c:1919 > #45 0xffffffff808e02be in bridge_output (ifp=0xfffff8000f2b7000, m=0xfffff8000f744400, sa=0x0, rt=0x0) > at /home/git/head/sys/net/if_bridge.c:2085 > #46 0xffffffff808e4b52 in ether_output (ifp=0xfffff8000f2b7000, m=0xfffff8000f744400, dst=0xfffff8000befe6b0, > ro=0xfffffe02d858d248) at /home/git/head/sys/net/if_ethersubr.c:376 > #47 0xffffffff8095cab7 in ieee80211_output (ifp=0xfffff8000f2b7000, m=0xfffff8000f744400, dst=0xfffff8000befe6b0, > ro=0xfffffe02d858d248) at /home/git/head/sys/net80211/ieee80211_output.c:576 > #48 0xffffffff809fd851 in ip_output (m=0xfffff8000f744400, opt=0x0, ro=0xfffffe02d858d248, flags=0x0, imo=0x0, > inp=0xfffff801f786c7d0) at /home/git/head/sys/netinet/ip_output.c:638 > #49 0xffffffff80ade593 in tcp_output (tp=0xfffff8016b2bc418) at /home/git/head/sys/netinet/tcp_output.c:1414 > #50 0xffffffff80ad59ee in tcp_do_segment (m=0xfffff8000f71d100, th=0xfffff800071f804a, so=0xfffff8016b5c92e8, > tp=0xfffff8016b2bc418, drop_hdrlen=0x34, tlen=0x544, iptos=0x0, ti_locked=0x1) > at /home/git/head/sys/netinet/tcp_input.c:1904 > #51 0xffffffff80ad3c9f in tcp_input (mp=0xfffffe02d858de28, offp=0xfffffe02d858de00, proto=0x6) > at /home/git/head/sys/netinet/tcp_input.c:1417 > #52 0xffffffff809f8b91 in ip_input (m=0x0) at /home/git/head/sys/netinet/ip_input.c:786 > #53 0xffffffff808f6b4e in netisr_dispatch_src (proto=0x1, source=0x0, m=0xfffff8000f71d100) > at /home/git/head/sys/net/netisr.c:972 > #54 0xffffffff808f7157 in netisr_dispatch (proto=0x1, m=0xfffff8000f71d100) at /home/git/head/sys/net/netisr.c:1063 > #55 0xffffffff808e55b0 in ether_demux (ifp=0xfffff8000f2b7000, m=0xfffff8000f71d100) > at /home/git/head/sys/net/if_ethersubr.c:805 > #56 0xffffffff808e7231 in ether_input_internal (ifp=0xfffff8000f2b7000, m=0xfffff8000f71d100) > at /home/git/head/sys/net/if_ethersubr.c:611 > #57 0xffffffff808e6a3f in ether_nh_input (m=0xfffff8000f71d100) at /home/git/head/sys/net/if_ethersubr.c:641 > #58 0xffffffff808f6b4e in netisr_dispatch_src (proto=0x5, source=0x0, m=0xfffff8000f71d100) > at /home/git/head/sys/net/netisr.c:972 > #59 0xffffffff808f7157 in netisr_dispatch (proto=0x5, m=0xfffff8000f71d100) at /home/git/head/sys/net/netisr.c:1063 > #60 0xffffffff808e5b6c in ether_input (ifp=0xfffff8000f2b7000, m=0xfffff8000f71d100) > at /home/git/head/sys/net/if_ethersubr.c:715 > #61 0xffffffff80938d6a in ieee80211_deliver_data (vap=0xfffff8000f2b1000, ni=0xfffffe0001817000, m=0xfffff8000f71d100) > at /home/git/head/sys/net80211/ieee80211_input.c:298 > #62 0xffffffff80974e77 in sta_input (ni=0xfffffe0001817000, m=0xfffff8000f71d100, rxs=0xfffffe02d858e440, rssi=0x82, > nf=0xb0) at /home/git/head/sys/net80211/ieee80211_sta.c:868 > #63 0xffffffff809383b8 in ieee80211_input_mimo (ni=0xfffffe0001817000, m=0xfffff8000f71d100, rx=0xfffffe02d858e560) > at /home/git/head/sys/net80211/ieee80211_input.c:103 > #64 0xffffffff804c158f in iwm_mvm_rx_rx_mpdu (sc=0xfffffe000108f000, pkt=0xfffff800071f8000, data=0xfffffe00010ce928) > at /home/git/head/sys/dev/iwm/if_iwm.c:2391 > #65 0xffffffff804bfe88 in iwm_notif_intr (sc=0xfffffe000108f000) at /home/git/head/sys/dev/iwm/if_iwm.c:4092 > #66 0xffffffff804bf55e in iwm_intr (arg=0xfffffe000108f000) at /home/git/head/sys/dev/iwm/if_iwm.c:4416 > #67 0xffffffff8070f7c8 in intr_event_execute_handlers (p=0xfffff80003df7aa0, ie=0xfffff80003def900) > at /home/git/head/sys/kern/kern_intr.c:1262 > #68 0xffffffff807105b7 in ithread_execute_handlers (p=0xfffff80003df7aa0, ie=0xfffff80003def900) > at /home/git/head/sys/kern/kern_intr.c:1275 > #69 0xffffffff807103e6 in ithread_loop (arg=0xfffff80007002500) at /home/git/head/sys/kern/kern_intr.c:1356 > #70 0xffffffff8070ad89 in fork_exit (callout=0xffffffff80710270 , arg=0xfffff80007002500, > frame=0xfffffe02d858eac0) at /home/git/head/sys/kern/kern_fork.c:1010 > #71 0xffffffff80c5447e in fork_trampoline () at /home/git/head/sys/amd64/amd64/exception.S:609 > #71 0xffffffff80c5447e in fork_trampoline () at /home/git/head/sys/amd64/amd64/exception.S:609 > > up 71 > 609 call fork_exit > > print $sp > $1 = (void *) 0xfffffe02d858eac0 > > > up 35 > #35 0xffffffff80c0cc36 in uma_dbg_getslab (zone=0xfffff80003e15000, item=0xfffff801f0e4b800) > at /home/git/head/sys/vm/uma_dbg.c:219 > 219 if (keg->uk_flags & UMA_ZONE_HASH) > > print $sp > $37 = (void *) 0xfffffe02d858beb0 > > so, 0x0eb0 bytes left on stack before fault at 0xfffffe02d858b000 > > > up 16 > #16 0xffffffff807a26c5 in cpu_search (cg=0xffffffff8146b148 , low=0xfffffe02d858b298, high=0x0, match=0x1) > at /home/git/head/sys/kern/sched_ule.c:689 > 689 cpu = CPU_FFS(&cpumask) - 1; > > print $sp > $56 = (void *) 0xfffffe02d858b000 > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Wed Jan 6 22:21:48 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D946A66A33 for ; Wed, 6 Jan 2016 22:21:48 +0000 (UTC) (envelope-from Sudarshan.NallanChakravarthy@netapp.com) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "mx144.netapp.com", Issuer "Symantec Class 3 Secure Server CA - G4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E83711DD6 for ; Wed, 6 Jan 2016 22:21:47 +0000 (UTC) (envelope-from Sudarshan.NallanChakravarthy@netapp.com) X-IronPort-AV: E=Sophos;i="5.20,530,1444719600"; d="scan'208,217";a="90560595" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx144-out.netapp.com with ESMTP; 06 Jan 2016 14:16:36 -0800 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 6 Jan 2016 14:16:36 -0800 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::b591:bd48:b520:c1b7%21]) with mapi id 15.00.1130.005; Wed, 6 Jan 2016 14:16:36 -0800 From: "NallanChakravarthy, Sudarshan" To: "freebsd-net@freebsd.org" Subject: DCB support on FreeBSD Thread-Topic: DCB support on FreeBSD Thread-Index: AQHRSM/nJ7rbFR3BOEKqsLPNpmWuAQ== Date: Wed, 6 Jan 2016 22:16:35 +0000 Message-ID: <6A2673C5-BB6D-40E2-B834-DEDD0E82CF45@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151217 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 22:21:48 -0000 SGVsbG8gRm9sa3MsDQpJIHdvdWxkIGxpa2UgdG8gZm9sbG93LWlwIG9uIGEgcG9zdCBpbiBmcmVl YnNkLW5ldC4gSXTigJlzIGFib3V0IERhdGEgQ2VudGVyIEJyaWRnaW5nIHN1cHBvcnQgaW4gRnJl ZUJTRCBrZXJuZWwuDQpZb3UgY2FuIGZpbmQgdGhlIGRpc2N1c3Npb24gYXQNCmh0dHA6Ly9mcmVl YnNkLW5ldC5mcmVlYnNkLm5hcmtpdmUuY29tLzhPMlZiQVE2L2RhdGEtY2VudGVyLWJyaWRnaW5n DQoNCkkgY291bGQgbm90IHJlcGx5IHRvIHRoaXMgdGhyZWFkIGRpcmVjdGx5LiBQbGVhc2UgbGV0 IG1lIGtub3cgdGhlIGN1cnJlbnQgc3RhdHVzIGlmIHNvbWVvbmUga25vd3Mgb3IgZGlyZWN0IG1l IHRvIHRoZSBhcHByb3ByaWF0ZSBkbC4NCg0KVGhhbmtzLA0KU3VkYXJzaGFuDQoNCg== From owner-freebsd-net@freebsd.org Wed Jan 6 22:29:11 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B387BA66C46 for ; Wed, 6 Jan 2016 22:29:11 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 3B36010C0 for ; Wed, 6 Jan 2016 22:29:11 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-lf0-x232.google.com with SMTP id z124so316609413lfa.3 for ; Wed, 06 Jan 2016 14:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KoUzIBcSfBZfVKn0vV2TiMOtxjJWWT7fnggSrtpnaig=; b=tPNsPVcIueY/97Y37vUlslfkLxkT8mGPSg4/zKxRcf1V54VqYg6CtMZZ7nt6mawQbk EsQ5nFZdWrRlj9O+QX43gmvyqqKbhh5pHm/5XYL/RoLfpcyeTCfav+8pyGTlEWDtv7c6 drvfbTIW8wQuJEBY+rIoI3Z2QNdskk7xHT4VXoUxHTr9UTcQxIFySo32x4Tl7qmT9KXH CGazY9HcDPiVNt+uNYER4+6t6EQD2IicfOXcpZMehcQmtxEXHKijcJaKuxu/RnLqWxZE FcWxv+dt3lq7Iw+DvAMf3uxgRpZK1Td4ys6Ls0UgiNjTdu7ozUUG6eAn5eEGqrLJm51Z ISKg== MIME-Version: 1.0 X-Received: by 10.25.148.141 with SMTP id w135mr12561252lfd.137.1452119349261; Wed, 06 Jan 2016 14:29:09 -0800 (PST) Received: by 10.25.89.10 with HTTP; Wed, 6 Jan 2016 14:29:09 -0800 (PST) Date: Wed, 6 Jan 2016 23:29:09 +0100 Message-ID: Subject: ppp(8) PPPoE fails when ifname contains "." From: Ben Woods To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 22:29:11 -0000 Hey everyone, I was recently trying to set up PPPoE to my ISP, over my network interface which is configured with 802.1q VLAN tagging using vlan(4). I utilised the vlans_= feature described in rc.conf(5), which creates a cloned interface named .. In /etc/ppp.conf I used the syntax PPPoE:. and this exposed an interesting issue - ppp(8) would not set up the PPPoE interface correctly when the interface contains a period. When I manually created the vlan clone interface with a name not containing a period, ppp(8) worked fine. Has anyone seen this before? A quick review of the ppp(8) code, and I am struggling to see the exact point where this syntax problem is. Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-net@freebsd.org Thu Jan 7 03:10:03 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D364A66ACA for ; Thu, 7 Jan 2016 03:10:03 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.rbsd.freebsd.org (unknown [IPv6:2607:fc50:2000:101::1bb:73]) by mx1.freebsd.org (Postfix) with ESMTP id 076D21E90 for ; Thu, 7 Jan 2016 03:10:03 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.rbsd.freebsd.org (Postfix, from userid 1346) id F2BA7331E6D6; Thu, 7 Jan 2016 03:10:02 +0000 (UTC) Date: Thu, 7 Jan 2016 03:10:02 +0000 To: freebsd-net@freebsd.org From: "rpokala (Ravi Pokala)" Reply-to: D1986+325+381818416dc12ca2@reviews.freebsd.org Subject: [Differential] [Updated, 335 lines] D1986: Teach lagg(4) to change MTU Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , Thread-Topic: D1986: Teach lagg(4) to change MTU X-Herald-Rules: none, <28> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ODZhMzNlYThiYzMxOTgzYmRhMDE5M2Q2Yzk4IFaN1wo= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_ae0c3951d155fc575d5ae5a13c002e93" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 03:10:03 -0000 --b1_ae0c3951d155fc575d5ae5a13c002e93 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit rpokala updated this revision to Diff 11984. rpokala marked 8 inline comments as done. rpokala added a comment. Address review comments from smh@, melifaro@, and hrs@. REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1986?vs=11321&id=11984 BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D1986 AFFECTED FILES sys/kern/kern_condvar.c sys/net/if_lagg.c sys/net/if_lagg.h sys/sys/condvar.h EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: rpokala, rstone, rpokala-panasas.com Cc: smh, imp, melifaro, hrs, sbruno, lakshmi.n_msystechnologies.com, emaste, ae, freebsd-net-list --b1_ae0c3951d155fc575d5ae5a13c002e93 Content-Type: text/x-patch; charset=utf-8; name="D1986.11984.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D1986.11984.patch" ZGlmZiAtLWdpdCBhL3N5cy9zeXMvY29uZHZhci5oIGIvc3lzL3N5cy9jb25kdmFyLmgKLS0tIGEv c3lzL3N5cy9jb25kdmFyLmgKKysrIGIvc3lzL3N5cy9jb25kdmFyLmgKQEAgLTYxLDYgKzYxLDcg QEAKIAkgICAgc2JpbnRpbWVfdCBzYnQsIHNiaW50aW1lX3QgcHIsIGludCBmbGFncyk7CiAKIHZv aWQJY3Zfc2lnbmFsKHN0cnVjdCBjdiAqY3ZwKTsKK2Jvb2wJY3ZfaGFzX3dhaXRlcnMoc3RydWN0 IGN2ICpjdnApOwogdm9pZAljdl9icm9hZGNhc3Rwcmkoc3RydWN0IGN2ICpjdnAsIGludCBwcmkp OwogCiAjZGVmaW5lCWN2X3dhaXQoY3ZwLCBsb2NrKQkJCQkJCVwKZGlmZiAtLWdpdCBhL3N5cy9u ZXQvaWZfbGFnZy5oIGIvc3lzL25ldC9pZl9sYWdnLmgKLS0tIGEvc3lzL25ldC9pZl9sYWdnLmgK KysrIGIvc3lzL25ldC9pZl9sYWdnLmgKQEAgLTIxLDYgKzIxLDggQEAKICNpZm5kZWYgX05FVF9M QUdHX0gKICNkZWZpbmUgX05FVF9MQUdHX0gKIAorI2luY2x1ZGUgPHN5cy9jb25kdmFyLmg+CisK IC8qCiAgKiBHbG9iYWwgZGVmaW5pdGlvbnMKICAqLwpAQCAtMjA2LDE4ICsyMDgsNTYgQEAKIAlM QUdHX0xMUVRZUEVfVklSVCwJLyogVGFzayByZWxhdGVkIHRvIGxhZ2cgaW50ZXJmYWNlIGl0c2Vs ZiAqLwogfSBsYWdnX2xscXR5cGU7CiAKLS8qIExpc3Qgb2YgaW50ZXJmYWNlcyB0byBoYXZlIHRo ZSBNQUMgYWRkcmVzcyBtb2RpZmllZCAqLwotc3RydWN0IGxhZ2dfbGxxIHsKKy8qIEFkZGluZyBu ZXcgZW50cnkgaGVyZSwgU0hPVUxEIGFsc28gaGF2ZSByZWxldmFudCBlbnRyeSBpbiBsbHFfYWN0 aW9uICovCit0eXBlZGVmIGVudW0geworCUxBR0dfTExRX01JTiA9IDAsCisJTEFHR19MTFFfTExB RERSID0gTEFHR19MTFFfTUlOLCAvKiBNQUMgQWRkcmVzcyBpbmRleCAqLworCUxBR0dfTExRX01U VSwgLyogIE1UVSBpbmRleCAqLworCisJTEFHR19MTFFfTUFYIC8qIFRoaXMgU0hPVUxEIGJlIHRo ZSBsYXN0IGVudHJ5ICovCit9IGxhZ2dfbGxxX2lkeDsKKworLyogQ29tbW9uIGxpc3QgZW50cnkg ZGVmaW5pdGlvbiBmb3IgZWFjaCB0YXNrcSBvcGVyYXRpb24gKi8KK3N0cnVjdCBsYWdnX2xscV9z bGlzdF9lbnRyeSB7CisJU0xJU1RfRU5UUlkobGFnZ19sbHFfc2xpc3RfZW50cnkpCWxscV9lbnRy aWVzOworfTsKKworLyogQ29udGV4dCBmb3IgbGxhZGRyIGxscSBvcGVyYXRpb24gcGFydCBvZiBs YWdnIHNvZnQgY29udGV4dCAqLworc3RydWN0IGxhZ2dfbGxhZGRyX2xscV9jdHh0IHsKKwlzdHJ1 Y3QgbGFnZ19sbHFfc2xpc3RfZW50cnkgbGxxX2NtbjsJLyogVGhpcyBTSE9VTEQgYmUgdGhlIGZp cnN0CisJCQkJCQkgICBtZW1iZXIgKi8KIAlzdHJ1Y3QgaWZuZXQJCSpsbHFfaWZwOwogCXVpbnQ4 X3QJCQlsbHFfbGxhZGRyW0VUSEVSX0FERFJfTEVOXTsKIAlsYWdnX2xscXR5cGUJCWxscV90eXBl OwotCVNMSVNUX0VOVFJZKGxhZ2dfbGxxKQlsbHFfZW50cmllczsKK307CisKKy8qIENvbnRleHQg Zm9yIG10dSBsbHEgb3BlcmF0aW9uIHBhcnQgb2YgbGFnZyBzb2Z0IGNvbnRleHQgKi8KK3N0cnVj dCBsYWdnX210dV9sbHFfY3R4dCB7CisJc3RydWN0IGxhZ2dfbGxxX3NsaXN0X2VudHJ5IGxscV9j bW47CS8qIFRoaXMgU0hPVUxEIGJlIHRoZSBmaXJzdAorCQkJCQkJICAgbWVtYmVyICovCisJc3Ry dWN0IGlmbmV0CQkqbGxxX2lmcDsKKwlzdHJ1Y3QgaWZyZXEJCWxscV9pZnI7CisJdWludDMyX3QJ CWxscV9vbGRfbXR1OworCWludAkJCSgqbGxxX2lvY3RsKShzdHJ1Y3QgaWZuZXQgKiwgdV9sb25n LCBjYWRkcl90KTsKIH07CiAKIHN0cnVjdCBsYWdnX2NvdW50ZXJzIHsKIAl1aW50NjRfdAl2YWxb SUZDT1VOVEVSU107CiB9OwogCisvKiBDb25kaXRpb25hbCB2YXJpYWJsZXMgY29udGV4dCBmb3Ig bGFnZyBvcGVyYXRpb25zICovCitzdHJ1Y3QgbGFnZ19zaWduYWwgeworCXN0cnVjdCBtdHgJCWxv Y2s7CisJc3RydWN0IGN2CQljdjsKK307CisKKy8qIExhZ2cgTVRVIGNvbnRleHQgKi8KK3N0cnVj dCBsYWdnX210dV9jdHh0IHsKKwlzdHJ1Y3QgbGFnZ19zaWduYWwJbXR1X3NlcmlhbDsJLyogU2Vy aWFsaXplIGJldHdlZW4gdGhlIGNvbW1hbmRzICovCisJc3RydWN0IGxhZ2dfc2lnbmFsCW10dV9z eW5jOwkvKiBTeW5jaHJvbml6ZSBmb3IgY29tbWFuZCBjb21wbGV0aW9uICovCisJaW50CQkJbXR1 X2NtZF9yZXQ7Cit9OworCiBzdHJ1Y3QgbGFnZ19zb2Z0YyB7CiAJc3RydWN0IGlmbmV0CQkJKnNj X2lmcDsJLyogdmlydHVhbCBpbnRlcmZhY2UgKi8KIAlzdHJ1Y3Qgcm1sb2NrCQkJc2NfbXR4OwpA QCAtMjM1LDkgKzI3NSwxMSBAQAogCVNMSVNUX0hFQUQoX190cGxoZCwgbGFnZ19wb3J0KQlzY19w b3J0czsJLyogbGlzdCBvZiBpbnRlcmZhY2VzICovCiAJU0xJU1RfRU5UUlkobGFnZ19zb2Z0YykJ c2NfZW50cmllczsKIAotCXN0cnVjdCB0YXNrCQkJc2NfbGxhZGRyX3Rhc2s7Ci0JU0xJU1RfSEVB RChfX2xscWhkLCBsYWdnX2xscSkJc2NfbGxxX2hlYWQ7CS8qIGludGVyZmFjZXMgdG8gcHJvZ3Jh bQotCQkJCQkJCSAgIHRoZSBsbGFkZHIgb24gKi8KKwlzdHJ1Y3QgdGFzawkJCXNjX2xscV90YXNr OwkvKiBTWU5DICYgQVNZTkMgb3BzIGVucXVldWVkIGhlcmUgKi8KKwlzdHJ1Y3QgbGFnZ19tdHVf Y3R4dAkJc2NfbXR1X2N0eHQ7CS8qIE1UVSBwcm9ncmFtbWluZyAqLworCS8qICBMaXN0IG9mIExM UXMgKi8KKwlTTElTVF9IRUFEKF9fbGxxaGQsIGxhZ2dfbGxxX3NsaXN0X2VudHJ5KQlzY19sbHFb TEFHR19MTFFfTUFYXTsKKwogCWV2ZW50aGFuZGxlcl90YWcgdmxhbl9hdHRhY2g7CiAJZXZlbnRo YW5kbGVyX3RhZyB2bGFuX2RldGFjaDsKIAlzdHJ1Y3QgY2FsbG91dAkJCXNjX2NhbGxvdXQ7CmRp ZmYgLS1naXQgYS9zeXMvbmV0L2lmX2xhZ2cuYyBiL3N5cy9uZXQvaWZfbGFnZy5jCi0tLSBhL3N5 cy9uZXQvaWZfbGFnZy5jCisrKyBiL3N5cy9uZXQvaWZfbGFnZy5jCkBAIC0xMDEsNyArMTAxLDEx IEBACiBzdGF0aWMgdm9pZAlsYWdnX2xsYWRkcihzdHJ1Y3QgbGFnZ19zb2Z0YyAqLCB1aW50OF90 ICopOwogc3RhdGljIHZvaWQJbGFnZ19jYXBhYmlsaXRpZXMoc3RydWN0IGxhZ2dfc29mdGMgKik7 CiBzdGF0aWMgdm9pZAlsYWdnX3BvcnRfbGxhZGRyKHN0cnVjdCBsYWdnX3BvcnQgKiwgdWludDhf dCAqLCBsYWdnX2xscXR5cGUpOwotc3RhdGljIHZvaWQJbGFnZ19wb3J0X3NldGxsYWRkcih2b2lk ICosIGludCk7CitzdGF0aWMgdm9pZAlsYWdnX3BvcnRfb3BzKHZvaWQgKiwgaW50KTsKK3N0YXRp YyB2b2lkCWxhZ2dfbGxxX2FjdGlvbl9tdHUoc3RydWN0IGxhZ2dfc29mdGMgKiwKKwkJc3RydWN0 IGxhZ2dfbGxxX3NsaXN0X2VudHJ5ICopOworc3RhdGljIHZvaWQJbGFnZ19sbHFfYWN0aW9uX2xs YWRkcihzdHJ1Y3QgbGFnZ19zb2Z0YyAqLAorCQlzdHJ1Y3QgbGFnZ19sbHFfc2xpc3RfZW50cnkg Kik7CiBzdGF0aWMgaW50CWxhZ2dfcG9ydF9jcmVhdGUoc3RydWN0IGxhZ2dfc29mdGMgKiwgc3Ry dWN0IGlmbmV0ICopOwogc3RhdGljIGludAlsYWdnX3BvcnRfZGVzdHJveShzdHJ1Y3QgbGFnZ19w b3J0ICosIGludCk7CiBzdGF0aWMgc3RydWN0IG1idWYgKmxhZ2dfaW5wdXQoc3RydWN0IGlmbmV0 ICosIHN0cnVjdCBtYnVmICopOwpAQCAtMTMwLDYgKzEzNCw5IEBACiBzdGF0aWMgdm9pZAlsYWdn X21lZGlhX3N0YXR1cyhzdHJ1Y3QgaWZuZXQgKiwgc3RydWN0IGlmbWVkaWFyZXEgKik7CiBzdGF0 aWMgc3RydWN0IGxhZ2dfcG9ydCAqbGFnZ19saW5rX2FjdGl2ZShzdHJ1Y3QgbGFnZ19zb2Z0YyAq LAogCSAgICBzdHJ1Y3QgbGFnZ19wb3J0ICopOworc3RhdGljIGludAlsYWdnX2NoYW5nZV9tdHUo c3RydWN0IGlmbmV0ICosIHN0cnVjdCBpZnJlcSAqKTsKK3N0YXRpYyB2b2lkCV9sYWdnX2xscV9j bGVhbnVwKHN0cnVjdCBsYWdnX2xscV9zbGlzdF9lbnRyeSAqKTsKK3N0YXRpYyB2b2lkCWxhZ2df bGxxX2NsZWFudXAoc3RydWN0IGxhZ2dfc29mdGMgKiwgbGFnZ19sbHFfaWR4KTsKIAogLyogU2lt cGxlIHJvdW5kIHJvYmluICovCiBzdGF0aWMgdm9pZAlsYWdnX3JyX2F0dGFjaChzdHJ1Y3QgbGFn Z19zb2Z0YyAqKTsKQEAgLTE2NSw2ICsxNzIsMjQgQEAKIAkJICAgIHN0cnVjdCBtYnVmICopOwog c3RhdGljIHZvaWQJbGFnZ19sYWNwX2xsYWRkcihzdHJ1Y3QgbGFnZ19zb2Z0YyAqKTsKIAorLyoK KyAqIFRoaXMgYWN0aW9uIGhhbmRsZXIgc2hhbGwgYmUgY2FsbGVkIGZyb20gdGFza3F1ZXVlIGhh bmRsZXIgZm9yIGVhY2gKKyAqIHN1Ym1pdHRlZCBvcGVyYXRpb24KKyAqLwordHlwZWRlZiB2b2lk ICgqbGFnZ19sbHFfYWN0aW9uKShzdHJ1Y3QgbGFnZ19zb2Z0YyAqLAorCQlzdHJ1Y3QgbGFnZ19s bHFfc2xpc3RfZW50cnkgKik7CisKKy8qCisgKiBsYWdnIGxscSBhY3Rpb24gVGFibGU6IENhbGxl ZCBhdCB0aGUgdGFza3F1ZXVlIGNvbnRleHQgZm9yIGVhY2gKKyAqIHN1Ym1pdHRlZCBvcGVyYXRp b25zLgorICogQ29udGVudHMgU0hPVUxEIGJlIGluIHN5bmMgd2l0aCBsYWdnX2xscV9pZHggaW5k ZXguCisgKiBOZXcgZW50cmllcyBzaGFsbCBiZSBhcHBlbmRlZC4KKyAqLworc3RhdGljIGNvbnN0 IGxhZ2dfbGxxX2FjdGlvbiBsbHFfYWN0aW9uW0xBR0dfTExRX01BWF0gPSB7CisJCWxhZ2dfbGxx X2FjdGlvbl9sbGFkZHIsIC8qIE1hcHMgdG8gTEFHR19MTFFfTExBRERSIGluZGV4ICovCisJCWxh Z2dfbGxxX2FjdGlvbl9tdHUsIC8qIE1hcHMgdG8gTEFHR19MTFFfTVRVIGluZGV4ICovCit9Owor CiAvKiBsYWdnIHByb3RvY29sIHRhYmxlICovCiBzdGF0aWMgY29uc3Qgc3RydWN0IGxhZ2dfcHJv dG8gewogCWxhZ2dfcHJvdG8JcHJfbnVtOwpAQCAtNDg3LDcgKzUxMiw3IEBACiAKIAlMQUdHX0xP Q0tfSU5JVChzYyk7CiAJU0xJU1RfSU5JVCgmc2MtPnNjX3BvcnRzKTsKLQlUQVNLX0lOSVQoJnNj LT5zY19sbGFkZHJfdGFzaywgMCwgbGFnZ19wb3J0X3NldGxsYWRkciwgc2MpOworCVRBU0tfSU5J VCgmc2MtPnNjX2xscV90YXNrLCAwLCBsYWdnX3BvcnRfb3BzLCBzYyk7CiAKIAkvKiBJbml0aWFs aXNlIHBzZXVkbyBtZWRpYSB0eXBlcyAqLwogCWlmbWVkaWFfaW5pdCgmc2MtPnNjX21lZGlhLCAw LCBsYWdnX21lZGlhX2NoYW5nZSwKQEAgLTUwNSw2ICs1MzAsMTMgQEAKIAlpZnAtPmlmX2ZsYWdz ID0gSUZGX1NJTVBMRVggfCBJRkZfQlJPQURDQVNUIHwgSUZGX01VTFRJQ0FTVDsKIAlpZnAtPmlm X2NhcGVuYWJsZSA9IGlmcC0+aWZfY2FwYWJpbGl0aWVzID0gSUZDQVBfSFdTVEFUUzsKIAorCW10 eF9pbml0KCZzYy0+c2NfbXR1X2N0eHQubXR1X3N5bmMubG9jaywgaWZwLT5pZl94bmFtZSwKKwkg ICAgIm10dV9zeW5jX2xvY2siLCBNVFhfREVGKTsKKwltdHhfaW5pdCgmc2MtPnNjX210dV9jdHh0 Lm10dV9zZXJpYWwubG9jaywgaWZwLT5pZl94bmFtZSwKKwkgICAgIm10dV9zZXJpYWxfbG9jayIs IE1UWF9ERUYpOworCWN2X2luaXQoJnNjLT5zY19tdHVfY3R4dC5tdHVfc3luYy5jdiwgIm10dV9z eW5jX2N2Iik7CisJY3ZfaW5pdCgmc2MtPnNjX210dV9jdHh0Lm10dV9zZXJpYWwuY3YsICJtdHVf c2VyaWFsX2N2Iik7CisKIAkvKgogCSAqIEF0dGFjaCBhcyBhbiBvcmRpbmFyeSBldGhlcm5ldCBk ZXZpY2UsIGNoaWxkcmVuIHdpbGwgYmUgYXR0YWNoZWQKIAkgKiBhcyBzcGVjaWFsIGRldmljZSBJ RlRfSUVFRTgwMjNBRExBRy4KQEAgLTU1Myw3ICs1ODUsMTEgQEAKIAlTTElTVF9SRU1PVkUoJlZf bGFnZ19saXN0LCBzYywgbGFnZ19zb2Z0Yywgc2NfZW50cmllcyk7CiAJTEFHR19MSVNUX1VOTE9D SygpOwogCi0JdGFza3F1ZXVlX2RyYWluKHRhc2txdWV1ZV9zd2ksICZzYy0+c2NfbGxhZGRyX3Rh c2spOworCXRhc2txdWV1ZV9kcmFpbih0YXNrcXVldWVfc3dpLCAmc2MtPnNjX2xscV90YXNrKTsK Kwljdl9kZXN0cm95KCZzYy0+c2NfbXR1X2N0eHQubXR1X3N5bmMuY3YpOworCWN2X2Rlc3Ryb3ko JnNjLT5zY19tdHVfY3R4dC5tdHVfc2VyaWFsLmN2KTsKKwltdHhfZGVzdHJveSgmc2MtPnNjX210 dV9jdHh0Lm10dV9zeW5jLmxvY2spOworCW10eF9kZXN0cm95KCZzYy0+c2NfbXR1X2N0eHQubXR1 X3NlcmlhbC5sb2NrKTsKIAlMQUdHX0xPQ0tfREVTVFJPWShzYyk7CiAJZnJlZShzYywgTV9ERVZC VUYpOwogfQpAQCAtNjQ1LDcgKzY4MSw4IEBACiB7CiAJc3RydWN0IGxhZ2dfc29mdGMgKnNjID0g bHAtPmxwX3NvZnRjOwogCXN0cnVjdCBpZm5ldCAqaWZwID0gbHAtPmxwX2lmcDsKLQlzdHJ1Y3Qg bGFnZ19sbHEgKmxscTsKKwlzdHJ1Y3QgbGFnZ19sbHFfc2xpc3RfZW50cnkgKmNtbl9sbHE7CisJ c3RydWN0IGxhZ2dfbGxhZGRyX2xscV9jdHh0ICpsbHFfY3R4dDsKIAogCUxBR0dfV0xPQ0tfQVNT RVJUKHNjKTsKIApAQCAtNjU4LDYyICs2OTUsMjIyIEBACiAJCXJldHVybjsKIAogCS8qIENoZWNr IHRvIG1ha2Ugc3VyZSBpdHMgbm90IGFscmVhZHkgcXVldWVkIHRvIGJlIGNoYW5nZWQgKi8KLQlT TElTVF9GT1JFQUNIKGxscSwgJnNjLT5zY19sbHFfaGVhZCwgbGxxX2VudHJpZXMpIHsKLQkJaWYg KGxscS0+bGxxX2lmcCA9PSBpZnApIHsKKwlTTElTVF9GT1JFQUNIKGNtbl9sbHEsICZzYy0+c2Nf bGxxW0xBR0dfTExRX0xMQUREUl0sIGxscV9lbnRyaWVzKSB7CisJCWxscV9jdHh0ID0gKHN0cnVj dCBsYWdnX2xsYWRkcl9sbHFfY3R4dCAqKWNtbl9sbHE7CisJCWlmIChsbHFfY3R4dC0+bGxxX2lm cCA9PSBpZnApIHsKIAkJCS8qIFVwZGF0ZSBsbGFkZHIsIGl0IG1heSBoYXZlIGNoYW5nZWQgKi8K LQkJCWJjb3B5KGxsYWRkciwgbGxxLT5sbHFfbGxhZGRyLCBFVEhFUl9BRERSX0xFTik7CisJCQli Y29weShsbGFkZHIsIGxscV9jdHh0LT5sbHFfbGxhZGRyLCBFVEhFUl9BRERSX0xFTik7CiAJCQly ZXR1cm47CiAJCX0KIAl9CiAKLQlsbHEgPSBtYWxsb2Moc2l6ZW9mKHN0cnVjdCBsYWdnX2xscSks IE1fREVWQlVGLCBNX05PV0FJVCB8IE1fWkVSTyk7Ci0JaWYgKGxscSA9PSBOVUxMKQkvKiBYWFgg d2hhdCB0byBkbyAqLworCWxscV9jdHh0ID0gbWFsbG9jKHNpemVvZihzdHJ1Y3QgbGFnZ19sbGFk ZHJfbGxxX2N0eHQpLCBNX0RFVkJVRiwKKwkgICAgTV9OT1dBSVQgfCBNX1pFUk8pOworCWlmIChs bHFfY3R4dCA9PSBOVUxMKQkvKiBYWFggd2hhdCB0byBkbyAqLwogCQlyZXR1cm47CiAKLQlsbHEt PmxscV9pZnAgPSBpZnA7Ci0JbGxxLT5sbHFfdHlwZSA9IGxscV90eXBlOwotCWJjb3B5KGxsYWRk ciwgbGxxLT5sbHFfbGxhZGRyLCBFVEhFUl9BRERSX0xFTik7CisJbGxxX2N0eHQtPmxscV9pZnAg PSBpZnA7CisJbGxxX2N0eHQtPmxscV90eXBlID0gbGxxX3R5cGU7CisJYmNvcHkobGxhZGRyLCBs bHFfY3R4dC0+bGxxX2xsYWRkciwgRVRIRVJfQUREUl9MRU4pOwogCS8qIFhYWDogV2Ugc2hvdWxk IGluc2VydCB0byB0YWlsICovCi0JU0xJU1RfSU5TRVJUX0hFQUQoJnNjLT5zY19sbHFfaGVhZCwg bGxxLCBsbHFfZW50cmllcyk7CisJU0xJU1RfSU5TRVJUX0hFQUQoJnNjLT5zY19sbHFbTEFHR19M TFFfTExBRERSXSwKKwkgICAgKHN0cnVjdCBsYWdnX2xscV9zbGlzdF9lbnRyeSAqKWxscV9jdHh0 LCBsbHFfZW50cmllcyk7CiAKLQl0YXNrcXVldWVfZW5xdWV1ZSh0YXNrcXVldWVfc3dpLCAmc2Mt PnNjX2xsYWRkcl90YXNrKTsKKwl0YXNrcXVldWVfZW5xdWV1ZSh0YXNrcXVldWVfc3dpLCAmc2Mt PnNjX2xscV90YXNrKTsKIH0KIAogLyoKLSAqIFNldCB0aGUgaW50ZXJmYWNlIE1BQyBhZGRyZXNz IGZyb20gYSB0YXNrcXVldWUgdG8gYXZvaWQgYSBMT1IuCisgKiBTZXQgdGhlIGludGVyZmFjZSBN VFUsIE1BQyBhZGRyZXNzIGZyb20gYSB0YXNrcXVldWUgdG8gYXZvaWQgYSBMT1IuCiAgKgogICog U2V0IG5vaW5saW5lIHRvIGJlIGR0cmFjZS1mcmllbmRseQogICovCiBzdGF0aWMgX19ub2lubGlu ZSB2b2lkCi1sYWdnX3BvcnRfc2V0bGxhZGRyKHZvaWQgKmFyZywgaW50IHBlbmRpbmcpCitsYWdn X3BvcnRfb3BzKHZvaWQgKmFyZywgaW50IHBlbmRpbmcpCiB7CiAJc3RydWN0IGxhZ2dfc29mdGMg KnNjID0gKHN0cnVjdCBsYWdnX3NvZnRjICopYXJnOwotCXN0cnVjdCBsYWdnX2xscSAqbGxxLCAq aGVhZDsKLQlzdHJ1Y3QgaWZuZXQgKmlmcDsKKwlzdHJ1Y3QgbGFnZ19sbHFfc2xpc3RfZW50cnkg KmxscV9maXJzdDsKKwlsYWdnX2xscV9pZHggbGxxX2lkeDsKKworCWZvciAobGxxX2lkeCA9IExB R0dfTExRX01JTjsgbGxxX2lkeCA8IExBR0dfTExRX01BWDsgbGxxX2lkeCsrKSB7CisJCUxBR0df V0xPQ0soc2MpOworCQlsbHFfZmlyc3QgPSBTTElTVF9GSVJTVCgmc2MtPnNjX2xscVtsbHFfaWR4 XSk7CisJCVNMSVNUX0lOSVQoJnNjLT5zY19sbHFbbGxxX2lkeF0pOworCQlMQUdHX1dVTkxPQ0so c2MpOworCisJCWlmIChsbHFfZmlyc3QgIT0gTlVMTCkKKwkJCWxscV9hY3Rpb25bbGxxX2lkeF0o c2MsIGxscV9maXJzdCk7CisJfQorfQogCi0JLyogR3JhYiBhIGxvY2FsIHJlZmVyZW5jZSBvZiB0 aGUgcXVldWUgYW5kIHJlbW92ZSBpdCBmcm9tIHRoZSBzb2Z0YyAqLworc3RhdGljIHZvaWQKK2xh Z2dfbGxxX2FjdGlvbl9tdHUoc3RydWN0IGxhZ2dfc29mdGMgKnNjLCBzdHJ1Y3QgbGFnZ19sbHFf c2xpc3RfZW50cnkgKmZpcnN0KQoreworCXN0cnVjdCBsYWdnX2xscV9zbGlzdF9lbnRyeSAqbGxx OworCWludCBlcnI7CisKKwkvKiBTZXQgdGhlIG5ldyBNVFUgb24gdGhlIGxhZ2cgaW50ZXJmYWNl ICovCiAJTEFHR19XTE9DSyhzYyk7Ci0JaGVhZCA9IFNMSVNUX0ZJUlNUKCZzYy0+c2NfbGxxX2hl YWQpOwotCVNMSVNUX0ZJUlNUKCZzYy0+c2NfbGxxX2hlYWQpID0gTlVMTDsKKwlzYy0+c2NfaWZw LT5pZl9tdHUgPSAoKHN0cnVjdCBsYWdnX210dV9sbHFfY3R4dCAqKWZpcnN0KS0+bGxxX2lmci5p ZnJfbXR1OwogCUxBR0dfV1VOTE9DSyhzYyk7CiAKIAkvKgorCSAqIFRyYXZlcnNlIHRoZSBxdWV1 ZSBhbmQgc2V0IHRoZSBtdHUgb24gZWFjaCBpZnAuIEl0IGlzIHNhZmUgdG8gZG8KKwkgKiB1bmxv Y2tlZCBhcyB3ZSBoYXZlIHRoZSBvbmx5IHJlZmVyZW5jZSB0byBpdC4KKwkgKi8KKwlsbHEgPSBm aXJzdDsKKwlTTElTVF9GT1JFQUNIX0ZST00obGxxLCAoc3RydWN0IF9fbGxxaGQgKilOVUxMLCBs bHFfZW50cmllcykgeworCQlzdHJ1Y3QgbGFnZ19tdHVfbGxxX2N0eHQgKmxscV9jdHh0OworCQls bHFfY3R4dCA9IChzdHJ1Y3QgbGFnZ19tdHVfbGxxX2N0eHQgKilsbHE7CisJCS8qIFNldCB0aGUg bmV3IE1UVSBvbiB0aGUgcGh5c2ljYWwgaW50ZXJmYWNlICovCisJCWVyciA9ICgqbGxxX2N0eHQt PmxscV9pb2N0bCkobGxxX2N0eHQtPmxscV9pZnAsIFNJT0NTSUZNVFUsCisJCSAgICAoY2FkZHJf dCkmbGxxX2N0eHQtPmxscV9pZnIpOworCQlpZiAoZXJyKSB7CisJCQlpZl9wcmludGYobGxxX2N0 eHQtPmxscV9pZnAsCisJCQkgICAgIkZhaWxlZCB0byBjaGFuZ2UgTVRVIGZyb20gJWQgdG8gJWQg KGVyciAlZClcbiIsCisJCQkgICAgbGxxX2N0eHQtPmxscV9vbGRfbXR1LCBsbHFfY3R4dC0+bGxx X2lmci5pZnJfbXR1LCBlcnIpOworCQkJYnJlYWs7CisJCX0KKwl9CisKKwlpZiAoZXJyKSB7CisJ CS8qIFJlc3RvcmUgdGhlIG9sZCBNVFUgb24gdGhlIGxhZ2cgaW50ZXJmYWNlICovCisJCUxBR0df V0xPQ0soc2MpOworCQlzYy0+c2NfaWZwLT5pZl9tdHUgPSAoKHN0cnVjdCBsYWdnX210dV9sbHFf Y3R4dCAqKWZpcnN0KS0+bGxxX29sZF9tdHU7CisJCUxBR0dfV1VOTE9DSyhzYyk7CisKKwkJLyog UmVzdG9yZSB0aGUgb2xkIE1UVSBvbiB0aGUgcGh5c2ljYWwgaW50ZXJmYWNlICovCisJCWxscSA9 IGZpcnN0OworCQlTTElTVF9GT1JFQUNIX0ZST00obGxxLCAoc3RydWN0IF9fbGxxaGQgKilOVUxM LCBsbHFfZW50cmllcykgeworCQkJc3RydWN0IGxhZ2dfbXR1X2xscV9jdHh0ICpsbHFfY3R4dDsK KwkJCWxscV9jdHh0ID0gKHN0cnVjdCBsYWdnX210dV9sbHFfY3R4dCAqKWxscTsKKwkJCWxscV9j dHh0LT5sbHFfaWZyLmlmcl9tdHUgPSBsbHFfY3R4dC0+bGxxX29sZF9tdHU7CisJCQllcnIgPSAo KmxscV9jdHh0LT5sbHFfaW9jdGwpCisJCQkgICAgKGxscV9jdHh0LT5sbHFfaWZwLCBTSU9DU0lG TVRVLCAoY2FkZHJfdCkmbGxxX2N0eHQtPmxscV9pZnIpOworCQkJaWYgKGVycikgeworCQkJCWlm X3ByaW50ZihsbHFfY3R4dC0+bGxxX2lmcCwKKwkJCQkgICAgIkZhaWxlZCB0byByZXN0b3JlIE1U VSB0byAlZCAoZXJyICVkKVxuIiwKKwkJCQkgICAgbGxxX2N0eHQtPmxscV9vbGRfbXR1LCBlcnIp OworCQkJfQorCQl9CisJfQorCisJLyogRnJlZSB0aGUgTVRVIExMUSBlbnRyaWVzICovCisJX2xh Z2dfbGxxX2NsZWFudXAoZmlyc3QpOworCisJbXR4X2xvY2soJnNjLT5zY19tdHVfY3R4dC5tdHVf c3luYy5sb2NrKTsKKwlzYy0+c2NfbXR1X2N0eHQubXR1X2NtZF9yZXQgPSBlcnI7CisJLyogU2ln bmFsIGZvciBjb21tYW5kIGNvbXBsZXRpb24gKi8KKwljdl9zaWduYWwoJnNjLT5zY19tdHVfY3R4 dC5tdHVfc3luYy5jdik7CisJbXR4X3VubG9jaygmc2MtPnNjX210dV9jdHh0Lm10dV9zeW5jLmxv Y2spOworfQorCitzdGF0aWMgdm9pZCBfbGFnZ19sbHFfY2xlYW51cChzdHJ1Y3QgbGFnZ19sbHFf c2xpc3RfZW50cnkgKmxscSkKK3sKKwlzdHJ1Y3QgbGFnZ19sbHFfc2xpc3RfZW50cnkgKnRtcF9s bHE7CisKKwlTTElTVF9GT1JFQUNIX0ZST01fU0FGRShsbHEsIChzdHJ1Y3QgX19sbHFoZCAqKU5V TEwsIGxscV9lbnRyaWVzLAorCSAgICB0bXBfbGxxKSB7CisJCWZyZWUobGxxLCBNX0RFVkJVRik7 CisJfQorfQorCitzdGF0aWMgdm9pZCBsYWdnX2xscV9jbGVhbnVwKHN0cnVjdCBsYWdnX3NvZnRj ICpzYywgbGFnZ19sbHFfaWR4IGlkeCkKK3sKKwlzdHJ1Y3QgbGFnZ19sbHFfc2xpc3RfZW50cnkg KmxscTsKKworCUxBR0dfV0xPQ0tfQVNTRVJUKHNjKTsKKworCWxscSA9IFNMSVNUX0ZJUlNUKCZz Yy0+c2NfbGxxW2lkeF0pOworCVNMSVNUX0lOSVQoJnNjLT5zY19sbHFbaWR4XSk7CisKKwlfbGFn Z19sbHFfY2xlYW51cChsbHEpOworfQorCitzdGF0aWMgaW50CitsYWdnX2NoYW5nZV9tdHUoc3Ry dWN0IGlmbmV0ICppZnAsIHN0cnVjdCBpZnJlcSAqaWZyKQoreworCXN0cnVjdCBsYWdnX3NvZnRj ICpzYzsKKwlzdHJ1Y3QgbGFnZ19wb3J0ICpscDsKKwlzdHJ1Y3QgbGFnZ19tdHVfbGxxX2N0eHQg KmxscV9jdHh0OworCWludCByZXQ7CisKKwlzYyA9IChzdHJ1Y3QgbGFnZ19zb2Z0YyAqKWlmcC0+ aWZfc29mdGM7CisKKwltdHhfbG9jaygmc2MtPnNjX210dV9jdHh0Lm10dV9zZXJpYWwubG9jayk7 CisJaWYgKGN2X2hhc193YWl0ZXJzKCZzYy0+c2NfbXR1X2N0eHQubXR1X3NlcmlhbC5jdikgPT0g VFJVRSkgeworCQkvKiBTZXJpYWxpemUgdGhlIGNvbW1hbmQgKi8KKwkJY3Zfd2FpdCgmc2MtPnNj X210dV9jdHh0Lm10dV9zZXJpYWwuY3YsCisJCSAgICAmc2MtPnNjX210dV9jdHh0Lm10dV9zZXJp YWwubG9jayk7CisJfQorCW10eF91bmxvY2soJnNjLT5zY19tdHVfY3R4dC5tdHVfc2VyaWFsLmxv Y2spOworCisJLyogTm8gY2hhbmdlIGluIE1UVSAqLworCWlmIChpZnAtPmlmX210dSA9PSBpZnIt Pmlmcl9tdHUpIHsKKwkJcmV0ID0gMDsKKwkJZ290byBvdXQ7CisJfQorCisJTEFHR19XTE9DSyhz Yyk7CisJLyogQWxsIGxhZ2cgcG9ydHMgKE1UVSBjaGFuZ2UpIHNoYWxsIGJlIHF1ZXVlZCBhdG9t aWMgKi8KKwlTTElTVF9GT1JFQUNIKGxwLCAmc2MtPnNjX3BvcnRzLCBscF9lbnRyaWVzKSB7CisJ CWxscV9jdHh0ID0gbWFsbG9jKHNpemVvZihzdHJ1Y3QgbGFnZ19tdHVfbGxxX2N0eHQpLCBNX0RF VkJVRiwKKwkJICAgIE1fTk9XQUlUKTsKKwkJaWYgKGxscV9jdHh0ID09IE5VTEwpIHsKKwkJCWxh Z2dfbGxxX2NsZWFudXAoc2MsIExBR0dfTExRX01UVSk7CisJCQlMQUdHX1dVTkxPQ0soc2MpOwor CQkJcmV0ID0gRU5PTUVNOworCQkJZ290byBvdXQ7CisJCX0KKwkJU0xJU1RfSU5TRVJUX0hFQUQo JnNjLT5zY19sbHFbTEFHR19MTFFfTVRVXSwKKwkJICAgIChzdHJ1Y3QgbGFnZ19sbHFfc2xpc3Rf ZW50cnkgKilsbHFfY3R4dCwgbGxxX2VudHJpZXMpOworCisJCWJjb3B5KGlmciwgJmxscV9jdHh0 LT5sbHFfaWZyLCBzaXplb2Yoc3RydWN0IGlmcmVxKSk7CisJCWxscV9jdHh0LT5sbHFfb2xkX210 dSA9IGlmcC0+aWZfbXR1OworCQlsbHFfY3R4dC0+bGxxX2lmcCA9IGxwLT5scF9pZnA7CisJCWxs cV9jdHh0LT5sbHFfaW9jdGwgPSBscC0+bHBfaW9jdGw7CisJfQorCW10eF9sb2NrKCZzYy0+c2Nf bXR1X2N0eHQubXR1X3N5bmMubG9jayk7CisJdGFza3F1ZXVlX2VucXVldWUodGFza3F1ZXVlX3N3 aSwgJnNjLT5zY19sbHFfdGFzayk7CisJTEFHR19XVU5MT0NLKHNjKTsKKworCS8qIFdhaXQgZm9y IHRoZSBjb21tYW5kIGNvbXBsZXRpb24gKi8KKwljdl93YWl0KCZzYy0+c2NfbXR1X2N0eHQubXR1 X3N5bmMuY3YsICZzYy0+c2NfbXR1X2N0eHQubXR1X3N5bmMubG9jayk7CisJcmV0ID0gc2MtPnNj X210dV9jdHh0Lm10dV9jbWRfcmV0OworCW10eF91bmxvY2soJnNjLT5zY19tdHVfY3R4dC5tdHVf c3luYy5sb2NrKTsKKworb3V0OgorCW10eF9sb2NrKCZzYy0+c2NfbXR1X2N0eHQubXR1X3Nlcmlh bC5sb2NrKTsKKwkvKiBTaWduYWwgdG8gcHJvY2VzcyB0aGUgbmV4dCBjb21tYW5kICovCisJY3Zf c2lnbmFsKCZzYy0+c2NfbXR1X2N0eHQubXR1X3NlcmlhbC5jdik7CisJbXR4X3VubG9jaygmc2Mt PnNjX210dV9jdHh0Lm10dV9zZXJpYWwubG9jayk7CisKKwlyZXR1cm4gKHJldCk7Cit9CisKK3N0 YXRpYyB2b2lkCitsYWdnX2xscV9hY3Rpb25fbGxhZGRyKHN0cnVjdCBsYWdnX3NvZnRjICpzYywg c3RydWN0IGxhZ2dfbGxxX3NsaXN0X2VudHJ5ICpoZWFkKQoreworCXN0cnVjdCBsYWdnX2xsYWRk cl9sbHFfY3R4dCAqbGxxX2N0eHQ7CisJc3RydWN0IGxhZ2dfbGxxX3NsaXN0X2VudHJ5ICpsbHE7 CisJc3RydWN0IGlmbmV0ICppZnA7CisKKwkvKgogCSAqIFRyYXZlcnNlIHRoZSBxdWV1ZSBhbmQg c2V0IHRoZSBsbGFkZHIgb24gZWFjaCBpZnAuIEl0IGlzIHNhZmUgdG8gZG8KIAkgKiB1bmxvY2tl ZCBhcyB3ZSBoYXZlIHRoZSBvbmx5IHJlZmVyZW5jZSB0byBpdC4KIAkgKi8KIAlmb3IgKGxscSA9 IGhlYWQ7IGxscSAhPSBOVUxMOyBsbHEgPSBoZWFkKSB7Ci0JCWlmcCA9IGxscS0+bGxxX2lmcDsK KwkJbGxxX2N0eHQgPSAoc3RydWN0IGxhZ2dfbGxhZGRyX2xscV9jdHh0ICopbGxxOworCQlpZnAg PSBsbHFfY3R4dC0+bGxxX2lmcDsKIAogCQlDVVJWTkVUX1NFVChpZnAtPmlmX3ZuZXQpOwogCiAJ CS8qCiAJCSAqIFNldCB0aGUgbGluayBsYXllciBhZGRyZXNzIG9uIHRoZSBsYWdncG9ydCBpbnRl cmZhY2UuCiAJCSAqIE5vdGUgdGhhdCBpZl9zZXRsbGFkZHIoKSBvciBpZmxsYWRkcl9ldmVudCBo YW5kbGVyCiAJCSAqIG1heSByZXN1bHQgaW4gYXJwIHRyYW5zbWlzc2lvbiAvIGxsdGFibGUgdXBk YXRlcy4KIAkJICovCi0JCWlmIChsbHEtPmxscV90eXBlID09IExBR0dfTExRVFlQRV9QSFlTKQot CQkJaWZfc2V0bGxhZGRyKGlmcCwgbGxxLT5sbHFfbGxhZGRyLAotCQkJICAgIEVUSEVSX0FERFJf TEVOKTsKKwkJaWYgKGxscV9jdHh0LT5sbHFfdHlwZSA9PSBMQUdHX0xMUVRZUEVfUEhZUykKKwkJ CWlmX3NldGxsYWRkcihpZnAsIGxscV9jdHh0LT5sbHFfbGxhZGRyLCBFVEhFUl9BRERSX0xFTik7 CiAJCWVsc2UKIAkJCUVWRU5USEFORExFUl9JTlZPS0UoaWZsbGFkZHJfZXZlbnQsIGlmcCk7CiAJ CUNVUlZORVRfUkVTVE9SRSgpOwpAQCAtODc3LDcgKzEwNzQsOCBAQAogewogCXN0cnVjdCBsYWdn X3NvZnRjICpzYyA9IGxwLT5scF9zb2Z0YzsKIAlzdHJ1Y3QgbGFnZ19wb3J0ICpscF9wdHIsICps cDA7Ci0Jc3RydWN0IGxhZ2dfbGxxICpsbHE7CisJc3RydWN0IGxhZ2dfbGxxX3NsaXN0X2VudHJ5 ICpjbW5fbGxxOworCXN0cnVjdCBsYWdnX2xsYWRkcl9sbHFfY3R4dCAqbGxxX2N0eHQ7CiAJc3Ry dWN0IGlmbmV0ICppZnAgPSBscC0+bHBfaWZwOwogCXVpbnQ2NF90ICpwdmFsLCB2ZGlmZjsKIAlp bnQgaTsKQEAgLTk0MCwxMSArMTEzOCwxMiBAQAogCiAJLyogUmVtb3ZlIGFueSBwZW5kaW5nIGxs YWRkciBjaGFuZ2VzIGZyb20gdGhlIHF1ZXVlICovCiAJaWYgKGxwLT5scF9kZXRhY2hpbmcpIHsK LQkJU0xJU1RfRk9SRUFDSChsbHEsICZzYy0+c2NfbGxxX2hlYWQsIGxscV9lbnRyaWVzKSB7Ci0J CQlpZiAobGxxLT5sbHFfaWZwID09IGlmcCkgewotCQkJCVNMSVNUX1JFTU9WRSgmc2MtPnNjX2xs cV9oZWFkLCBsbHEsIGxhZ2dfbGxxLAotCQkJCSAgICBsbHFfZW50cmllcyk7Ci0JCQkJZnJlZShs bHEsIE1fREVWQlVGKTsKKwkJU0xJU1RfRk9SRUFDSChjbW5fbGxxLCAmc2MtPnNjX2xscVtMQUdH X0xMUV9MTEFERFJdLCBsbHFfZW50cmllcykgeworCQkJbGxxX2N0eHQgPSAoc3RydWN0IGxhZ2df bGxhZGRyX2xscV9jdHh0ICopY21uX2xscTsKKwkJCWlmIChsbHFfY3R4dC0+bGxxX2lmcCA9PSBp ZnApIHsKKwkJCQlTTElTVF9SRU1PVkUoJnNjLT5zY19sbHFbTEFHR19MTFFfTExBRERSXSwgY21u X2xscSwKKwkJCQkgICAgbGFnZ19sbHFfc2xpc3RfZW50cnksIGxscV9lbnRyaWVzKTsKKwkJCQlm cmVlKGNtbl9sbHEsIE1fREVWQlVGKTsKIAkJCQlicmVhazsJLyogT25seSBhcHBlYXJzIG9uY2Ug Ki8KIAkJCX0KIAkJfQpAQCAtMTUyOSwxMCArMTcyOCwxMiBAQAogCQlicmVhazsKIAogCWNhc2Ug U0lPQ1NJRkNBUDoKLQljYXNlIFNJT0NTSUZNVFU6Ci0JCS8qIERvIG5vdCBhbGxvdyB0aGUgTVRV IG9yIGNhcHMgdG8gYmUgZGlyZWN0bHkgY2hhbmdlZCAqLworCQkvKiBEbyBub3QgYWxsb3cgdGhl IENBUHMgdG8gYmUgZGlyZWN0bHkgY2hhbmdlZC4gKi8KIAkJZXJyb3IgPSBFSU5WQUw7CiAJCWJy ZWFrOworCWNhc2UgU0lPQ1NJRk1UVToKKwkJZXJyb3IgPSBsYWdnX2NoYW5nZV9tdHUoaWZwLCBp ZnIpOworCQlicmVhazsKIAogCWRlZmF1bHQ6CiAJCWVycm9yID0gZXRoZXJfaW9jdGwoaWZwLCBj bWQsIGRhdGEpOwpkaWZmIC0tZ2l0IGEvc3lzL2tlcm4va2Vybl9jb25kdmFyLmMgYi9zeXMva2Vy bi9rZXJuX2NvbmR2YXIuYwotLS0gYS9zeXMva2Vybi9rZXJuX2NvbmR2YXIuYworKysgYi9zeXMv a2Vybi9rZXJuX2NvbmR2YXIuYwpAQCAtNDU1LDMgKzQ1NSwxNiBAQAogCWlmICh3YWtldXBfc3dh cHBlcikKIAkJa2lja19wcm9jMCgpOwogfQorCisvKgorICogUmV0dXJuIHRydWUgaWYgb25lIG9y IG1vcmUgTFdQcyBhcmUgd2FpdGluZyBvbiB0aGUgc3BlY2lmaWVkCisgKiBjb25kaXRpb24gdmFy aWFibGUuCisgKi8KK2Jvb2wKK2N2X2hhc193YWl0ZXJzKHN0cnVjdCBjdiAqY3ZwKQoreworCWlm IChjdnAtPmN2X3dhaXRlcnMgPiAwKQorCQlyZXR1cm4gKFRSVUUpOworCWVsc2UKKwkJcmV0dXJu IChGQUxTRSk7Cit9Cgo= --b1_ae0c3951d155fc575d5ae5a13c002e93-- From owner-freebsd-net@freebsd.org Thu Jan 7 09:51:27 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A24B8A666B7 for ; Thu, 7 Jan 2016 09:51:27 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 1173713AC for ; Thu, 7 Jan 2016 09:51:27 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id u188so91134767wmu.1 for ; Thu, 07 Jan 2016 01:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O+WFWEIdlsRDH4SSpd306TpOiAipnXhgz/fkkvO631A=; b=s4nFCLw7a97amxTFPDfwow9ol0xlEcnnpmHExeo8/OM247yP0iuMc7m71H1ldYICPs khcLtvXf6NXD6hlSoa+NKLG+KtEawuqhSSqWD5WGTqCHn/pb9008c1WZkZo6wZcRsHqb 2S6tLhdZ3H6cD1YWeIWZTiz83dtDB9kw+lBJt6+0Ya/XQeRdntxFXsW35BVgOv/CgGvv 7j7oqwt4qiJueKpuaz6VeVjTzs87JSjw7iHi+FSk65h4Vk296ftZgcY0jdRfSDsBMmFs JsfanXMkMnSUH115ipt8Dt8Xlv9QGT/7PLF8+i9uEeanPNfIylF1/s3TEZ5qovUElLo+ gVKg== MIME-Version: 1.0 X-Received: by 10.28.63.22 with SMTP id m22mr14641273wma.59.1452160284422; Thu, 07 Jan 2016 01:51:24 -0800 (PST) Received: by 10.28.136.148 with HTTP; Thu, 7 Jan 2016 01:51:24 -0800 (PST) In-Reply-To: <20160104210741.32812.qmail@f5-external.bushwire.net> References: <1451841004.10139.34.camel@me.com> <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> Date: Thu, 7 Jan 2016 11:51:24 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: Mark Delany Cc: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=001a114b3ebce94c900528bb6994 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:51:27 -0000 --001a114b3ebce94c900528bb6994 Content-Type: text/plain; charset=UTF-8 Hello, Here's my implementation of the two system calls. The patch is against HEAD from a couple of days: commit ff9e83788d7ed52342dcba4dff1e62fdf3cc985c Author: ngie Date: Mon Jan 4 03:34:22 2016 +0000 Remove free'ing of an uninitialized variable Just remove it completely from the test as it's initialized but unused apart from the free(3) call Differential Revision: https://reviews.freebsd.org/D4769 (part of larger diff) MFC after: 5 days Reported by: cppcheck Reviewed by: oshogbo Sponsored by: EMC / Isilon Storage Division I've made brief tests using the examples in the manpages in Linux skipping the timeout stuff: http://man7.org/linux/man-pages/man2/sendmmsg.2.html http://man7.org/linux/man-pages/man2/recvmmsg.2.html I've tried to stick to the comments in the thread but any suggestions/testings are also welcomed so that I can fix the calls accordingly. Regards, Boris Astardzhiev On Mon, Jan 4, 2016 at 11:07 PM, Mark Delany wrote: > > You just repeat arguments for the text in my messages, which you removed > > on reply. > > My goal is to get you to scruitinize. > > Thank you for helping. > > > Mark. > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --001a114b3ebce94c900528bb6994 Content-Type: text/plain; charset=US-ASCII; name="sendrecvmmsg.diff" Content-Disposition: attachment; filename="sendrecvmmsg.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ij42nfvu0 ZGlmZiAtLWdpdCBhL2xpYi9saWJjL2luY2x1ZGUvbGliY19wcml2YXRlLmggYi9saWIvbGliYy9p bmNsdWRlL2xpYmNfcHJpdmF0ZS5oCmluZGV4IDVjYWY5YTMuLjdlMmE5MDIgMTAwNjQ0Ci0tLSBh L2xpYi9saWJjL2luY2x1ZGUvbGliY19wcml2YXRlLmgKKysrIGIvbGliL2xpYmMvaW5jbHVkZS9s aWJjX3ByaXZhdGUuaApAQCAtMjAwLDggKzIwMCwxMCBAQCBlbnVtIHsKIAlJTlRFUlBPU19wc2Vs ZWN0LAogCUlOVEVSUE9TX3JlY3Zmcm9tLAogCUlOVEVSUE9TX3JlY3Ztc2csCisJSU5URVJQT1Nf cmVjdm1tc2csCiAJSU5URVJQT1Nfc2VsZWN0LAogCUlOVEVSUE9TX3NlbmRtc2csCisJSU5URVJQ T1Nfc2VuZG1tc2csCiAJSU5URVJQT1Nfc2VuZHRvLAogCUlOVEVSUE9TX3NldGNvbnRleHQsCiAJ SU5URVJQT1Nfc2lnYWN0aW9uLApAQCAtMjg5LDYgKzI5MSw3IEBAIHN0cnVjdCBmZF9zZXQ7CiBz dHJ1Y3QgaW92ZWM7CiBzdHJ1Y3Qga2V2ZW50Owogc3RydWN0IG1zZ2hkcjsKK3N0cnVjdCBtbXNn aGRyOwogc3RydWN0IHBvbGxmZDsKIHN0cnVjdCBydXNhZ2U7CiBzdHJ1Y3Qgc2lnYWN0aW9uOwpA QCAtMzM0LDkgKzMzNywxMSBAQCBfX3NzaXplX3QJX19zeXNfcmVjdihpbnQsIHZvaWQgKiwgX19z aXplX3QsIGludCk7CiBfX3NzaXplX3QJX19zeXNfcmVjdmZyb20oaW50LCB2b2lkICosIF9fc2l6 ZV90LCBpbnQsIHN0cnVjdCBzb2NrYWRkciAqLAogCQkgICAgX19zb2NrbGVuX3QgKik7CiBfX3Nz aXplX3QJX19zeXNfcmVjdm1zZyhpbnQsIHN0cnVjdCBtc2doZHIgKiwgaW50KTsKK19fc3NpemVf dAlfX3N5c19yZWN2bW1zZyhpbnQsIHN0cnVjdCBtbXNnaGRyICosIHVuc2lnbmVkIGludCwgaW50 KTsKIGludAkJX19zeXNfc2VsZWN0KGludCwgc3RydWN0IGZkX3NldCAqLCBzdHJ1Y3QgZmRfc2V0 ICosCiAJCSAgICBzdHJ1Y3QgZmRfc2V0ICosIHN0cnVjdCB0aW1ldmFsICopOwogX19zc2l6ZV90 CV9fc3lzX3NlbmRtc2coaW50LCBjb25zdCBzdHJ1Y3QgbXNnaGRyICosIGludCk7CitfX3NzaXpl X3QJX19zeXNfc2VuZG1tc2coaW50LCBjb25zdCBzdHJ1Y3QgbW1zZ2hkciAqLCB1bnNpZ25lZCBp bnQsIGludCk7CiBfX3NzaXplX3QJX19zeXNfc2VuZHRvKGludCwgY29uc3Qgdm9pZCAqLCBfX3Np emVfdCwgaW50LAogCQkgICAgY29uc3Qgc3RydWN0IHNvY2thZGRyICosIF9fc29ja2xlbl90KTsK IGludAkJX19zeXNfc2V0Y29udGV4dChjb25zdCBzdHJ1Y3QgX191Y29udGV4dCAqKTsKZGlmZiAt LWdpdCBhL2xpYi9saWJjL2luY2x1ZGUvbmFtZXNwYWNlLmggYi9saWIvbGliYy9pbmNsdWRlL25h bWVzcGFjZS5oCmluZGV4IDczOWQ3YjEuLmM5NTgyOWUgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL2lu Y2x1ZGUvbmFtZXNwYWNlLmgKKysrIGIvbGliL2xpYmMvaW5jbHVkZS9uYW1lc3BhY2UuaApAQCAt MjA4LDYgKzIwOCw3IEBACiAjZGVmaW5lCQlyZWFkdgkJCQlfcmVhZHYKICNkZWZpbmUJCXJlY3Zm cm9tCQkJX3JlY3Zmcm9tCiAjZGVmaW5lCQlyZWN2bXNnCQkJCV9yZWN2bXNnCisjZGVmaW5lCQly ZWN2bW1zZwkJCV9yZWN2bW1zZwogI2RlZmluZQkJc2VsZWN0CQkJCV9zZWxlY3QKICNkZWZpbmUJ CXNlbV9jbG9zZQkJCV9zZW1fY2xvc2UKICNkZWZpbmUJCXNlbV9kZXN0cm95CQkJX3NlbV9kZXN0 cm95CkBAIC0yMjAsNiArMjIxLDcgQEAKICNkZWZpbmUJCXNlbV91bmxpbmsJCQlfc2VtX3VubGlu awogI2RlZmluZQkJc2VtX3dhaXQJCQlfc2VtX3dhaXQKICNkZWZpbmUJCXNlbmRtc2cJCQkJX3Nl bmRtc2cKKyNkZWZpbmUJCXNlbmRtbXNnCQkJX3NlbmRtbXNnCiAjZGVmaW5lCQlzZW5kdG8JCQkJ X3NlbmR0bwogI2RlZmluZQkJc2V0c29ja29wdAkJCV9zZXRzb2Nrb3B0CiAvKiNkZWZpbmUJCXNp Z2FjdGlvbgkJCV9zaWdhY3Rpb24qLwpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvaW5jbHVkZS91bi1u YW1lc3BhY2UuaCBiL2xpYi9saWJjL2luY2x1ZGUvdW4tbmFtZXNwYWNlLmgKaW5kZXggZjMxZmE3 YS4uMDIzMzM0OCAxMDA2NDQKLS0tIGEvbGliL2xpYmMvaW5jbHVkZS91bi1uYW1lc3BhY2UuaAor KysgYi9saWIvbGliYy9pbmNsdWRlL3VuLW5hbWVzcGFjZS5oCkBAIC0xODksNiArMTg5LDcgQEAK ICN1bmRlZgkJcmVhZHYKICN1bmRlZgkJcmVjdmZyb20KICN1bmRlZgkJcmVjdm1zZworI3VuZGVm CQlyZWN2bW1zZwogI3VuZGVmCQlzZWxlY3QKICN1bmRlZgkJc2VtX2Nsb3NlCiAjdW5kZWYJCXNl bV9kZXN0cm95CkBAIC0yMDEsNiArMjAyLDcgQEAKICN1bmRlZgkJc2VtX3VubGluawogI3VuZGVm CQlzZW1fd2FpdAogI3VuZGVmCQlzZW5kbXNnCisjdW5kZWYJCXNlbmRtbXNnCiAjdW5kZWYJCXNl bmR0bwogI3VuZGVmCQlzZXRzb2Nrb3B0CiAjdW5kZWYJCXNpZ2FjdGlvbgpkaWZmIC0tZ2l0IGEv bGliL2xpYmMvc3lzL01ha2VmaWxlLmluYyBiL2xpYi9saWJjL3N5cy9NYWtlZmlsZS5pbmMKaW5k ZXggZTRmZTFiMi4uMWMwOWZjZSAxMDA2NDQKLS0tIGEvbGliL2xpYmMvc3lzL01ha2VmaWxlLmlu YworKysgYi9saWIvbGliYy9zeXMvTWFrZWZpbGUuaW5jCkBAIC00OSw4ICs0OSwxMCBAQCBJTlRF UlBPU0VEID0gXAogCXJlYWR2IFwKIAlyZWN2ZnJvbSBcCiAJcmVjdm1zZyBcCisJcmVjdm1tc2cg XAogCXNlbGVjdCBcCiAJc2VuZG1zZyBcCisJc2VuZG1tc2cgXAogCXNlbmR0byBcCiAJc2V0Y29u dGV4dCBcCiAJc2lncHJvY21hc2sgXApkaWZmIC0tZ2l0IGEvbGliL2xpYmMvc3lzL1N5bWJvbC5t YXAgYi9saWIvbGliYy9zeXMvU3ltYm9sLm1hcAppbmRleCA3YjMyNTdjLi42Y2MzYzZlIDEwMDY0 NAotLS0gYS9saWIvbGliYy9zeXMvU3ltYm9sLm1hcAorKysgYi9saWIvbGliYy9zeXMvU3ltYm9s Lm1hcApAQCAtMjIwLDYgKzIyMCw3IEBAIEZCU0RfMS4wIHsKIAlyZWJvb3Q7CiAJcmVjdmZyb207 CiAJcmVjdm1zZzsKKwlyZWN2bW1zZzsKIAlyZW5hbWU7CiAJcmV2b2tlOwogCXJmb3JrOwpAQCAt MjQwLDYgKzI0MSw3IEBAIEZCU0RfMS4wIHsKIAlzZW1zeXM7CiAJc2VuZGZpbGU7CiAJc2VuZG1z ZzsKKwlzZW5kbW1zZzsKIAlzZW5kdG87CiAJc2V0YXVkaXQ7CiAJc2V0YXVkaXRfYWRkcjsKQEAg LTg1MSw2ICs4NTMsOCBAQCBGQlNEcHJpdmF0ZV8xLjAgewogCV9fc3lzX3JlY3Zmcm9tOwogCV9y ZWN2bXNnOwogCV9fc3lzX3JlY3Ztc2c7CisJX3JlY3ZtbXNnOworCV9fc3lzX3JlY3ZtbXNnOwog CV9yZW5hbWU7CiAJX19zeXNfcmVuYW1lOwogCV9yZXZva2U7CkBAIC04OTEsNiArODk1LDggQEAg RkJTRHByaXZhdGVfMS4wIHsKIAlfX3N5c19zZW5kZmlsZTsKIAlfc2VuZG1zZzsKIAlfX3N5c19z ZW5kbXNnOworCV9zZW5kbW1zZzsKKwlfX3N5c19zZW5kbW1zZzsKIAlfc2VuZHRvOwogCV9fc3lz X3NlbmR0bzsKIAlfc2V0YXVkaXQ7CmRpZmYgLS1naXQgYS9saWIvbGliYy9zeXMvaW50ZXJwb3Np bmdfdGFibGUuYyBiL2xpYi9saWJjL3N5cy9pbnRlcnBvc2luZ190YWJsZS5jCmluZGV4IDA4ZGZi YjEuLmM4NjZhNzUgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL3N5cy9pbnRlcnBvc2luZ190YWJsZS5j CisrKyBiL2xpYi9saWJjL3N5cy9pbnRlcnBvc2luZ190YWJsZS5jCkBAIC01Niw4ICs1NiwxMCBA QCBpbnRlcnBvc19mdW5jX3QgX19saWJjX2ludGVycG9zaW5nW0lOVEVSUE9TX01BWF0gPSB7CiAJ U0xPVChyZWFkdiwgX19zeXNfcmVhZHYpLAogCVNMT1QocmVjdmZyb20sIF9fc3lzX3JlY3Zmcm9t KSwKIAlTTE9UKHJlY3Ztc2csIF9fc3lzX3JlY3Ztc2cpLAorCVNMT1QocmVjdm1tc2csIF9fc3lz X3JlY3ZtbXNnKSwKIAlTTE9UKHNlbGVjdCwgX19zeXNfc2VsZWN0KSwKIAlTTE9UKHNlbmRtc2cs IF9fc3lzX3NlbmRtc2cpLAorCVNMT1Qoc2VuZG1tc2csIF9fc3lzX3NlbmRtbXNnKSwKIAlTTE9U KHNlbmR0bywgX19zeXNfc2VuZHRvKSwKIAlTTE9UKHNldGNvbnRleHQsIF9fc3lzX3NldGNvbnRl eHQpLAogCVNMT1Qoc2lnYWN0aW9uLCBfX3N5c19zaWdhY3Rpb24pLApkaWZmIC0tZ2l0IGEvbGli L2xpYmMvc3lzL3JlY3ZtbXNnLmMgYi9saWIvbGliYy9zeXMvcmVjdm1tc2cuYwpuZXcgZmlsZSBt b2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi5iYmIwNTg4Ci0tLSAvZGV2L251bGwKKysrIGIvbGli L2xpYmMvc3lzL3JlY3ZtbXNnLmMKQEAgLTAsMCArMSw0NyBAQAorLyoKKyAqIENvcHlyaWdodCAo YykgMjAxNiBCb3JpcyBBc3RhcmR6aGlldiwgU21hcnRjb20tQnVsZ2FyaWEgQUQKKyAqIEFsbCBy aWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2Ug YW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBw ZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBt ZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhl IGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlKHMpLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9u cyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGFzCisgKiAgICB0aGUgZmlyc3QgbGluZXMg b2YgdGhpcyBmaWxlIHVubW9kaWZpZWQgb3RoZXIgdGhhbiB0aGUgcG9zc2libGUKKyAqICAgIGFk ZGl0aW9uIG9mIG9uZSBvciBtb3JlIGNvcHlyaWdodCBub3RpY2VzLgorICogMi4gUmVkaXN0cmli dXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQK KyAqICAgIG5vdGljZShzKSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dp bmcgZGlzY2xhaW1lciBpbgorICogICAgdGhlIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1h dGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZQorICogICAgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRI SVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIENPUFlSSUdIVCBIT0xERVIoUykgYGBBUyBJ UycnIEFORCBBTlkKKyAqIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcs IEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hB TlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIKKyAqIFBVUlBPU0UgQVJFIERJ U0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQ09QWVJJR0hUIEhPTERFUihTKSBCRQor ICogTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwg RVhFTVBMQVJZLCBPUgorICogQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBO T1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YKKyAqIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VS VklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUgorICogQlVTSU5FU1MgSU5U RVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFks CisgKiBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUIChJTkNM VURJTkcgTkVHTElHRU5DRQorICogT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VU IE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwKKyAqIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUg UE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCisgKi8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5o PgorX19GQlNESUQoIiRGcmVlQlNEJCIpOworCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5j bHVkZSA8c3lzL3N5c2NhbGwuaD4KKyNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+CisjaW5jbHVkZSAi bGliY19wcml2YXRlLmgiCisKK19fd2Vha19yZWZlcmVuY2UoX19zeXNfcmVjdm1tc2csIF9fcmVj dm1tc2cpOworCisjcHJhZ21hIHdlYWsgcmVjdm1tc2cKK3NzaXplX3QKK3JlY3ZtbXNnKGludCBz LCBzdHJ1Y3QgbW1zZ2hkciAqbXNndmVjLCB1bnNpZ25lZCBpbnQgdmxlbiwgaW50IGZsYWdzKQor eworCisJcmV0dXJuICgoKGludCAoKikoaW50LCBzdHJ1Y3QgbW1zZ2hkciAqLCBpbnQsIGludCkp CisJICAgIF9fbGliY19pbnRlcnBvc2luZ1tJTlRFUlBPU19yZWN2bW1zZ10pKHMsIG1zZ3ZlYywg dmxlbiwgZmxhZ3MpKTsKK30KZGlmZiAtLWdpdCBhL2xpYi9saWJjL3N5cy9zZW5kbW1zZy5jIGIv bGliL2xpYmMvc3lzL3NlbmRtbXNnLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAw MC4uMzk4ZjljYQotLS0gL2Rldi9udWxsCisrKyBiL2xpYi9saWJjL3N5cy9zZW5kbW1zZy5jCkBA IC0wLDAgKzEsNDcgQEAKKy8qCisgKiBDb3B5cmlnaHQgKGMpIDIwMTYgQm9yaXMgQXN0YXJkemhp ZXYsIFNtYXJ0Y29tLUJ1bGdhcmlhIEFECisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAq IFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGgg b3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQg dGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRp b25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAg IG5vdGljZShzKSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lciBhcworICogICAgdGhlIGZpcnN0IGxpbmVzIG9mIHRoaXMgZmlsZSB1bm1vZGlmaWVk IG90aGVyIHRoYW4gdGhlIHBvc3NpYmxlCisgKiAgICBhZGRpdGlvbiBvZiBvbmUgb3IgbW9yZSBj b3B5cmlnaHQgbm90aWNlcy4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBt dXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UocyksIHRoaXMg bGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4KKyAqICAg IHRoZSBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0 aGUKKyAqICAgIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVE IEJZIFRIRSBDT1BZUklHSFQgSE9MREVSKFMpIGBgQVMgSVMnJyBBTkQgQU5ZCisgKiBFWFBSRVNT IE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRI RQorICogSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBG T1IgQSBQQVJUSUNVTEFSCisgKiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQg U0hBTEwgVEhFIENPUFlSSUdIVCBIT0xERVIoUykgQkUKKyAqIExJQUJMRSBGT1IgQU5ZIERJUkVD VCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IKKyAqIENPTlNF UVVFTlRJQUwgREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVN RU5UIE9GCisgKiBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFU QSwgT1IgUFJPRklUUzsgT1IKKyAqIEJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVT RUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLAorICogV0hFVEhFUiBJTiBDT05UUkFD VCwgU1RSSUNUIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UKKyAqIE9S IE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09G VFdBUkUsCisgKiBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFN QUdFLgorICovCisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRCQi KTsKKworI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9zeXNjYWxsLmg+Cisj aW5jbHVkZSA8c3lzL3NvY2tldC5oPgorI2luY2x1ZGUgImxpYmNfcHJpdmF0ZS5oIgorCitfX3dl YWtfcmVmZXJlbmNlKF9fc3lzX3NlbmRtbXNnLCBfX3NlbmRtbXNnKTsKKworI3ByYWdtYSB3ZWFr IHNlbmRtbXNnCitzc2l6ZV90CitzZW5kbW1zZyhpbnQgcywgY29uc3Qgc3RydWN0IG1tc2doZHIg Km1zZ3ZlYywgdW5zaWduZWQgaW50IHZsZW4sIGludCBmbGFncykKK3sKKworCXJldHVybiAoKChp bnQgKCopKGludCwgY29uc3Qgc3RydWN0IG1tc2doZHIgKiwgaW50LCBpbnQpKQorCSAgICBfX2xp YmNfaW50ZXJwb3NpbmdbSU5URVJQT1Nfc2VuZG1tc2ddKShzLCBtc2d2ZWMsIHZsZW4sIGZsYWdz KSk7Cit9CmRpZmYgLS1naXQgYS9zeXMvYnNtL2F1ZGl0X2tldmVudHMuaCBiL3N5cy9ic20vYXVk aXRfa2V2ZW50cy5oCmluZGV4IDNjMTZjNzMuLjJmYzg4N2EgMTAwNjQ0Ci0tLSBhL3N5cy9ic20v YXVkaXRfa2V2ZW50cy5oCisrKyBiL3N5cy9ic20vYXVkaXRfa2V2ZW50cy5oCkBAIC02MTEsNiAr NjExLDggQEAKICNkZWZpbmUJQVVFX0JJTkRBVAkJNDMyMDcJLyogVHJ1c3RlZEJTRC4gKi8KICNk ZWZpbmUJQVVFX0NPTk5FQ1RBVAkJNDMyMDgJLyogVHJ1c3RlZEJTRC4gKi8KICNkZWZpbmUJQVVF X0NIRkxBR1NBVAkJNDMyMDkJLyogRnJlZUJTRC1zcGVjaWZpYy4gKi8KKyNkZWZpbmUJQVVFX1NF TkRNTVNHCQk0MzIxMAorI2RlZmluZQlBVUVfUkVDVk1NU0cJCTQzMjExCiAKIC8qCiAgKiBEYXJ3 aW4gQlNNIHVzZXMgYSBudW1iZXIgb2YgQVVFX09fKiBkZWZpbml0aW9ucywgd2hpY2ggYXJlIGFs aWFzZWQgdG8gdGhlCmRpZmYgLS1naXQgYS9zeXMva2Vybi9pbml0X3N5c2VudC5jIGIvc3lzL2tl cm4vaW5pdF9zeXNlbnQuYwppbmRleCAwOWVjMDVkLi40MDFkNzg1IDEwMDY0NAotLS0gYS9zeXMv a2Vybi9pbml0X3N5c2VudC5jCisrKyBiL3N5cy9rZXJuL2luaXRfc3lzZW50LmMKQEAgLTMsNyAr Myw3IEBACiAgKgogICogRE8gTk9UIEVESVQtLSB0aGlzIGZpbGUgaXMgYXV0b21hdGljYWxseSBn ZW5lcmF0ZWQuCiAgKiAkRnJlZUJTRCQKLSAqIGNyZWF0ZWQgZnJvbSBGcmVlQlNEOiBoZWFkL3N5 cy9rZXJuL3N5c2NhbGxzLm1hc3RlciAyODUzODggMjAxNS0wNy0xMSAxNToyMjoxMVogYWRyaWFu IAorICogY3JlYXRlZCBmcm9tIEZyZWVCU0QKICAqLwogCiAjaW5jbHVkZSAib3B0X2NvbXBhdC5o IgpAQCAtNTkwLDQgKzU5MCw2IEBAIHN0cnVjdCBzeXNlbnQgc3lzZW50W10gPSB7CiAJeyBBUyh1 dGltZW5zYXRfYXJncyksIChzeV9jYWxsX3QgKilzeXNfdXRpbWVuc2F0LCBBVUVfRlVUSU1FU0FU LCBOVUxMLCAwLCAwLCBTWUZfQ0FQRU5BQkxFRCwgU1lfVEhSX1NUQVRJQyB9LAkvKiA1NDcgPSB1 dGltZW5zYXQgKi8KIAl7IEFTKG51bWFfZ2V0YWZmaW5pdHlfYXJncyksIChzeV9jYWxsX3QgKilz eXNfbnVtYV9nZXRhZmZpbml0eSwgQVVFX05VTEwsIE5VTEwsIDAsIDAsIDAsIFNZX1RIUl9TVEFU SUMgfSwJLyogNTQ4ID0gbnVtYV9nZXRhZmZpbml0eSAqLwogCXsgQVMobnVtYV9zZXRhZmZpbml0 eV9hcmdzKSwgKHN5X2NhbGxfdCAqKXN5c19udW1hX3NldGFmZmluaXR5LCBBVUVfTlVMTCwgTlVM TCwgMCwgMCwgMCwgU1lfVEhSX1NUQVRJQyB9LAkvKiA1NDkgPSBudW1hX3NldGFmZmluaXR5ICov CisJeyBBUyhzZW5kbW1zZ19hcmdzKSwgKHN5X2NhbGxfdCAqKXN5c19zZW5kbW1zZywgQVVFX1NF TkRNTVNHLCBOVUxMLCAwLCAwLCAwLCBTWV9USFJfU1RBVElDIH0sCS8qIDU1MCA9IHNlbmRtbXNn ICovCisJeyBBUyhyZWN2bW1zZ19hcmdzKSwgKHN5X2NhbGxfdCAqKXN5c19yZWN2bW1zZywgQVVF X1JFQ1ZNTVNHLCBOVUxMLCAwLCAwLCAwLCBTWV9USFJfU1RBVElDIH0sCS8qIDU1MSA9IHJlY3Zt bXNnICovCiB9OwpkaWZmIC0tZ2l0IGEvc3lzL2tlcm4vc3lzY2FsbHMuYyBiL3N5cy9rZXJuL3N5 c2NhbGxzLmMKaW5kZXggMWVkYjE5My4uN2UwZDM4NDAgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL3N5 c2NhbGxzLmMKKysrIGIvc3lzL2tlcm4vc3lzY2FsbHMuYwpAQCAtMyw3ICszLDcgQEAKICAqCiAg KiBETyBOT1QgRURJVC0tIHRoaXMgZmlsZSBpcyBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlZC4KICAq ICRGcmVlQlNEJAotICogY3JlYXRlZCBmcm9tIEZyZWVCU0Q6IGhlYWQvc3lzL2tlcm4vc3lzY2Fs bHMubWFzdGVyIDI4NTM4OCAyMDE1LTA3LTExIDE1OjIyOjExWiBhZHJpYW4gCisgKiBjcmVhdGVk IGZyb20gRnJlZUJTRAogICovCiAKIGNvbnN0IGNoYXIgKnN5c2NhbGxuYW1lc1tdID0gewpAQCAt NTU3LDQgKzU1Nyw2IEBAIGNvbnN0IGNoYXIgKnN5c2NhbGxuYW1lc1tdID0gewogCSJ1dGltZW5z YXQiLAkJCS8qIDU0NyA9IHV0aW1lbnNhdCAqLwogCSJudW1hX2dldGFmZmluaXR5IiwJCQkvKiA1 NDggPSBudW1hX2dldGFmZmluaXR5ICovCiAJIm51bWFfc2V0YWZmaW5pdHkiLAkJCS8qIDU0OSA9 IG51bWFfc2V0YWZmaW5pdHkgKi8KKwkic2VuZG1tc2ciLAkJCS8qIDU1MCA9IHNlbmRtbXNnICov CisJInJlY3ZtbXNnIiwJCQkvKiA1NTEgPSByZWN2bW1zZyAqLwogfTsKZGlmZiAtLWdpdCBhL3N5 cy9rZXJuL3N5c2NhbGxzLm1hc3RlciBiL3N5cy9rZXJuL3N5c2NhbGxzLm1hc3RlcgppbmRleCA2 ZTZmYjM4Li42MTkwODk1IDEwMDY0NAotLS0gYS9zeXMva2Vybi9zeXNjYWxscy5tYXN0ZXIKKysr IGIvc3lzL2tlcm4vc3lzY2FsbHMubWFzdGVyCkBAIC05OTQsNiArOTk0LDEwIEBACiA1NDkJQVVF X05VTEwJU1RECXsgaW50IG51bWFfc2V0YWZmaW5pdHkoY3B1d2hpY2hfdCB3aGljaCwgXAogCQkJ CSAgICBpZF90IGlkLCBcCiAJCQkJICAgIGNvbnN0IHN0cnVjdCB2bV9kb21haW5fcG9saWN5X2Vu dHJ5ICpwb2xpY3kpOyB9Cis1NTAJQVVFX1NFTkRNTVNHCVNURAl7IGludCBzZW5kbW1zZyhpbnQg cywgc3RydWN0IG1tc2doZHIgKm1zZ3ZlYyxcCisJCQkJICAgIHVuc2lnbmVkIGludCB2bGVuLCBp bnQgZmxhZ3MpOyB9Cis1NTEJQVVFX1JFQ1ZNTVNHCVNURAl7IGludCByZWN2bW1zZyhpbnQgcywg c3RydWN0IG1tc2doZHIgKm1zZ3ZlYyxcCisJCQkJICAgIHVuc2lnbmVkIGludCB2bGVuLCBpbnQg ZmxhZ3MpOyB9CiAKIDsgUGxlYXNlIGNvcHkgYW55IGFkZGl0aW9ucyBhbmQgY2hhbmdlcyB0byB0 aGUgZm9sbG93aW5nIGNvbXBhdGFiaWxpdHkgdGFibGVzOgogOyBzeXMvY29tcGF0L2ZyZWVic2Qz Mi9zeXNjYWxscy5tYXN0ZXIKZGlmZiAtLWdpdCBhL3N5cy9rZXJuL3N5c3RyYWNlX2FyZ3MuYyBi L3N5cy9rZXJuL3N5c3RyYWNlX2FyZ3MuYwppbmRleCAwMGEwNTBmLi43YzBkODYyIDEwMDY0NAot LS0gYS9zeXMva2Vybi9zeXN0cmFjZV9hcmdzLmMKKysrIGIvc3lzL2tlcm4vc3lzdHJhY2VfYXJn cy5jCkBAIC0zMzU1LDYgKzMzNTUsMjYgQEAgc3lzdHJhY2VfYXJncyhpbnQgc3lzbnVtLCB2b2lk ICpwYXJhbXMsIHVpbnQ2NF90ICp1YXJnLCBpbnQgKm5fYXJncykKIAkJKm5fYXJncyA9IDM7CiAJ CWJyZWFrOwogCX0KKwkvKiBzZW5kbW1zZyAqLworCWNhc2UgNTUwOiB7CisJCXN0cnVjdCBzZW5k bW1zZ19hcmdzICpwID0gcGFyYW1zOworCQlpYXJnWzBdID0gcC0+czsgLyogaW50ICovCisJCXVh cmdbMV0gPSAoaW50cHRyX3QpIHAtPm1zZ3ZlYzsgLyogc3RydWN0IG1tc2doZHIgKiAqLworCQl1 YXJnWzJdID0gcC0+dmxlbjsgLyogdW5zaWduZWQgaW50ICovCisJCWlhcmdbM10gPSBwLT5mbGFn czsgLyogaW50ICovCisJCSpuX2FyZ3MgPSA0OworCQlicmVhazsKKwl9CisJLyogcmVjdm1tc2cg Ki8KKwljYXNlIDU1MTogeworCQlzdHJ1Y3QgcmVjdm1tc2dfYXJncyAqcCA9IHBhcmFtczsKKwkJ aWFyZ1swXSA9IHAtPnM7IC8qIGludCAqLworCQl1YXJnWzFdID0gKGludHB0cl90KSBwLT5tc2d2 ZWM7IC8qIHN0cnVjdCBtbXNnaGRyICogKi8KKwkJdWFyZ1syXSA9IHAtPnZsZW47IC8qIHVuc2ln bmVkIGludCAqLworCQlpYXJnWzNdID0gcC0+ZmxhZ3M7IC8qIGludCAqLworCQkqbl9hcmdzID0g NDsKKwkJYnJlYWs7CisJfQogCWRlZmF1bHQ6CiAJCSpuX2FyZ3MgPSAwOwogCQlicmVhazsKQEAg LTg5MzMsNiArODk1Myw0NCBAQCBzeXN0cmFjZV9lbnRyeV9zZXRhcmdkZXNjKGludCBzeXNudW0s IGludCBuZHgsIGNoYXIgKmRlc2MsIHNpemVfdCBkZXNjc3opCiAJCQlicmVhazsKIAkJfTsKIAkJ YnJlYWs7CisJLyogc2VuZG1tc2cgKi8KKwljYXNlIDU1MDoKKwkJc3dpdGNoKG5keCkgeworCQlj YXNlIDA6CisJCQlwID0gImludCI7CisJCQlicmVhazsKKwkJY2FzZSAxOgorCQkJcCA9ICJzdHJ1 Y3QgbW1zZ2hkciAqIjsKKwkJCWJyZWFrOworCQljYXNlIDI6CisJCQlwID0gInVuc2lnbmVkIGlu dCI7CisJCQlicmVhazsKKwkJY2FzZSAzOgorCQkJcCA9ICJpbnQiOworCQkJYnJlYWs7CisJCWRl ZmF1bHQ6CisJCQlicmVhazsKKwkJfTsKKwkJYnJlYWs7CisJLyogcmVjdm1tc2cgKi8KKwljYXNl IDU1MToKKwkJc3dpdGNoKG5keCkgeworCQljYXNlIDA6CisJCQlwID0gImludCI7CisJCQlicmVh azsKKwkJY2FzZSAxOgorCQkJcCA9ICJzdHJ1Y3QgbW1zZ2hkciAqIjsKKwkJCWJyZWFrOworCQlj YXNlIDI6CisJCQlwID0gInVuc2lnbmVkIGludCI7CisJCQlicmVhazsKKwkJY2FzZSAzOgorCQkJ cCA9ICJpbnQiOworCQkJYnJlYWs7CisJCWRlZmF1bHQ6CisJCQlicmVhazsKKwkJfTsKKwkJYnJl YWs7CiAJZGVmYXVsdDoKIAkJYnJlYWs7CiAJfTsKQEAgLTEwODY2LDYgKzEwOTI0LDE2IEBAIHN5 c3RyYWNlX3JldHVybl9zZXRhcmdkZXNjKGludCBzeXNudW0sIGludCBuZHgsIGNoYXIgKmRlc2Ms IHNpemVfdCBkZXNjc3opCiAJCWlmIChuZHggPT0gMCB8fCBuZHggPT0gMSkKIAkJCXAgPSAiaW50 IjsKIAkJYnJlYWs7CisJLyogc2VuZG1tc2cgKi8KKwljYXNlIDU1MDoKKwkJaWYgKG5keCA9PSAw IHx8IG5keCA9PSAxKQorCQkJcCA9ICJpbnQiOworCQlicmVhazsKKwkvKiByZWN2bW1zZyAqLwor CWNhc2UgNTUxOgorCQlpZiAobmR4ID09IDAgfHwgbmR4ID09IDEpCisJCQlwID0gImludCI7CisJ CWJyZWFrOwogCWRlZmF1bHQ6CiAJCWJyZWFrOwogCX07CmRpZmYgLS1naXQgYS9zeXMva2Vybi91 aXBjX3N5c2NhbGxzLmMgYi9zeXMva2Vybi91aXBjX3N5c2NhbGxzLmMKaW5kZXggYzMzYTJjZi4u NzM1NGI0ZiAxMDA2NDQKLS0tIGEvc3lzL2tlcm4vdWlwY19zeXNjYWxscy5jCisrKyBiL3N5cy9r ZXJuL3VpcGNfc3lzY2FsbHMuYwpAQCAtMTAzOCw2ICsxMDM4LDgyIEBAIHN5c19zZW5kbXNnKHRk LCB1YXApCiB9CiAKIGludAorc3lzX3NlbmRtbXNnKHRkLCB1YXApCisJc3RydWN0IHRocmVhZCAq dGQ7CisJc3RydWN0IHNlbmRtbXNnX2FyZ3MgLyogeworCQlpbnQJczsKKwkJc3RydWN0IG1tc2do ZHIJKm1zZ3ZlYzsKKwkJdW5zaWduZWQgaW50CXZsZW47CisJCWludAlmbGFnczsKKwl9ICovICp1 YXA7Cit7CisJc3RydWN0IG1tc2doZHIgKnZlYywgKm1tcDsKKwlzdHJ1Y3QgbXNnaGRyICptcCwg bXNnOworCXN0cnVjdCBpb3ZlYyAqaW92OworCXVuc2lnbmVkIGludCB2bGVuLCBsZW47CisJaW50 IGksIHNlbnQgPSAwLCBlcnJvcjsKKwlzdHJ1Y3Qgc29ja2V0ICpzbyA9IE5VTEw7CisJc3RydWN0 IGZpbGUgKmZwOworCWNhcF9yaWdodHNfdCByaWdodHM7CisKKwlpZiAoZmdldCh0ZCwgdWFwLT5z LCBjYXBfcmlnaHRzX2luaXQoJnJpZ2h0cywgQ0FQX1NFTkQpLCAmZnApICE9IDApCisJCXJldHVy biAoRUJBREYpOworCisJc28gPSBmcC0+Zl9kYXRhOworCisJdmxlbiA9IHVhcC0+dmxlbjsKKwlp ZiAodmxlbiA+IFVJT19NQVhJT1YpCisJCXZsZW4gPSBVSU9fTUFYSU9WOworCisJbGVuID0gdmxl biAqIHNpemVvZigqdWFwLT5tc2d2ZWMpOworCXZlYyA9IG1hbGxvYyhsZW4sIE1fVEVNUCwgTV9X QUlUT0spOworCisJZXJyb3IgPSBjb3B5aW4odWFwLT5tc2d2ZWMsIHZlYywgbGVuKTsKKwlpZiAo ZXJyb3IgIT0gMCkKKwkJZ290byBvdXQ7CisKKwlmb3IgKGkgPSAwOyBpIDwgdmxlbjsgaSsrKSB7 CisJCW1tcCA9ICZ2ZWNbaV07CisJCW1wID0gJm1tcC0+bXNnX2hkcjsKKwkJbXNnID0gKm1wOwor CisJCWVycm9yID0gY29weWluaW92KG1zZy5tc2dfaW92LCBtc2cubXNnX2lvdmxlbiwgJmlvdiwg RU1TR1NJWkUpOworCQlpZiAoZXJyb3IgIT0gMCkKKwkJCWdvdG8gb3V0OworCisJCW1zZy5tc2df aW92ID0gaW92OworI2lmZGVmIENPTVBBVF9PTERTT0NLCisJCW1zZy5tc2dfZmxhZ3MgPSAwOwor I2VuZGlmCisJCWVycm9yID0gc2VuZGl0KHRkLCB1YXAtPnMsICZtc2csIHVhcC0+ZmxhZ3MpOwor CQlmcmVlKGlvdiwgTV9JT1YpOworCQlpZiAoZXJyb3IgIT0gMCkKKwkJCWdvdG8gb3V0OworCisJ CWVycm9yID0gY29weW91dCgmdGQtPnRkX3JldHZhbFswXSwgJnVhcC0+bXNndmVjW2ldLm1zZ19s ZW4sCisJCSAgICBzaXplb2YodGQtPnRkX3JldHZhbFswXSkpOworCQlpZiAoZXJyb3IgIT0gMCkK KwkJCWdvdG8gb3V0OworCisJCXNlbnQrKzsKKwl9CisKKwl0ZC0+dGRfcmV0dmFsWzBdID0gc2Vu dDsKKworb3V0OgorCWlmIChlcnJvciAhPSAwICYmIHNlbnQgIT0gMCAmJiBzZW50ICE9IHZsZW4p IHsKKwkJc28tPnNvX2Vycm9yID0gZXJyb3I7CisJCWVycm9yID0gMDsKKwkJdGQtPnRkX3JldHZh bFswXSA9IHNlbnQ7CisJfQorCisJZmRyb3AoZnAsIHRkKTsKKworCWZyZWUodmVjLCBNX1RFTVAp OworCXJldHVybiAoZXJyb3IpOworfQorCitpbnQKIGtlcm5fcmVjdml0KHRkLCBzLCBtcCwgZnJv bXNlZywgY29udHJvbHApCiAJc3RydWN0IHRocmVhZCAqdGQ7CiAJaW50IHM7CkBAIC0xMzYzLDYg KzE0MzksOTEgQEAgc3lzX3JlY3Ztc2codGQsIHVhcCkKIAlyZXR1cm4gKGVycm9yKTsKIH0KIAor aW50CitzeXNfcmVjdm1tc2codGQsIHVhcCkKKwlzdHJ1Y3QgdGhyZWFkICp0ZDsKKwlzdHJ1Y3Qg cmVjdm1tc2dfYXJncyAvKiB7CisJCWludAlzOworCQlzdHJ1Y3QgbW1zZ2hkcgkqbXNndmVjOwor CQl1bnNpZ25lZCBpbnQJdmxlbjsKKwkJaW50CWZsYWdzOworCX0gKi8gKnVhcDsKK3sKKwlzdHJ1 Y3QgbW1zZ2hkciAqdmVjLCAqbW1wOworCXN0cnVjdCBtc2doZHIgKm1wLCBtc2c7CisJc3RydWN0 IGlvdmVjICp1aW92LCAqaW92OworCXVuc2lnbmVkIGludCB2bGVuLCBsZW47CisJaW50IGksIHJj dmQgPSAwLCBlcnJvcjsKKwlzdHJ1Y3Qgc29ja2V0ICpzbyA9IE5VTEw7CisJc3RydWN0IGZpbGUg KmZwOworCWNhcF9yaWdodHNfdCByaWdodHM7CisKKwlpZiAoZmdldCh0ZCwgdWFwLT5zLCBjYXBf cmlnaHRzX2luaXQoJnJpZ2h0cywgQ0FQX1JFQ1YpLCAmZnApICE9IDApCisJCXJldHVybiAoRUJB REYpOworCisJc28gPSBmcC0+Zl9kYXRhOworCisJdmxlbiA9IHVhcC0+dmxlbjsKKwlpZiAodmxl biA+IFVJT19NQVhJT1YpCisJCXZsZW4gPSBVSU9fTUFYSU9WOworCisJbGVuID0gdmxlbiAqIHNp emVvZigqdWFwLT5tc2d2ZWMpOworCXZlYyA9IG1hbGxvYyhsZW4sIE1fVEVNUCwgTV9XQUlUT0sp OworCisJZXJyb3IgPSBjb3B5aW4odWFwLT5tc2d2ZWMsIHZlYywgbGVuKTsKKwlpZiAoZXJyb3Ig IT0gMCkKKwkJZ290byBvdXQ7CisKKwlmb3IgKGkgPSAwOyBpIDwgdmxlbjsgaSsrKSB7CisJCW1t cCA9ICZ2ZWNbaV07CisJCW1wID0gJm1tcC0+bXNnX2hkcjsKKwkJbXNnID0gKm1wOworCisJCWVy cm9yID0gY29weWluaW92KG1zZy5tc2dfaW92LCBtc2cubXNnX2lvdmxlbiwgJmlvdiwgRU1TR1NJ WkUpOworCQlpZiAoZXJyb3IgIT0gMCkKKwkJCWdvdG8gb3V0OworCisJCW1zZy5tc2dfZmxhZ3Mg PSB1YXAtPmZsYWdzOworI2lmZGVmIENPTVBBVF9PTERTT0NLCisJCW1zZy5tc2dfZmxhZ3MgJj0g fk1TR19DT01QQVQ7CisjZW5kaWYKKwkJdWlvdiA9IG1zZy5tc2dfaW92OworCQltc2cubXNnX2lv diA9IGlvdjsKKworCQllcnJvciA9IHJlY3ZpdCh0ZCwgdWFwLT5zLCAmbXNnLCBOVUxMKTsKKwkJ aWYgKGVycm9yID09IDApIHsKKwkJCW1zZy5tc2dfaW92ID0gdWlvdjsKKwkJCWVycm9yID0gY29w eW91dCgmbXNnLCAmdWFwLT5tc2d2ZWNbaV0ubXNnX2hkciwgc2l6ZW9mKG1zZykpOworCQkJaWYg KGVycm9yICE9IDApIHsKKwkJCQlmcmVlKGlvdiwgTV9JT1YpOworCQkJCWdvdG8gb3V0OworCQkJ fQorCQkJZXJyb3IgPSBjb3B5b3V0KCZ0ZC0+dGRfcmV0dmFsWzBdLCAmdWFwLT5tc2d2ZWNbaV0u bXNnX2xlbiwKKwkJCSAgICBzaXplb2YodGQtPnRkX3JldHZhbFswXSkpOworCQkJaWYgKGVycm9y ICE9IDApIHsKKwkJCQlmcmVlKGlvdiwgTV9JT1YpOworCQkJCWdvdG8gb3V0OworCQkJfQorCQl9 CisJCWZyZWUoaW92LCBNX0lPVik7CisJCXJjdmQrKzsKKwl9CisKKwl0ZC0+dGRfcmV0dmFsWzBd ID0gcmN2ZDsKKworb3V0OgorCWlmIChlcnJvciAhPSAwICYmIHJjdmQgIT0gMCAmJiByY3ZkICE9 IHZsZW4pIHsKKwkJc28tPnNvX2Vycm9yID0gZXJyb3I7CisJCWVycm9yID0gMDsKKwkJdGQtPnRk X3JldHZhbFswXSA9IHJjdmQ7CisJfQorCisJZmRyb3AoZnAsIHRkKTsKKworCWZyZWUodmVjLCBN X1RFTVApOworCXJldHVybiAoZXJyb3IpOworfQorCiAvKiBBUkdTVVNFRCAqLwogaW50CiBzeXNf c2h1dGRvd24odGQsIHVhcCkKZGlmZiAtLWdpdCBhL3N5cy9zeXMvc29ja2V0LmggYi9zeXMvc3lz L3NvY2tldC5oCmluZGV4IDE4ZTJkZTEuLmQzNTJjZDIgMTAwNjQ0Ci0tLSBhL3N5cy9zeXMvc29j a2V0LmgKKysrIGIvc3lzL3N5cy9zb2NrZXQuaApAQCAtNDE0LDYgKzQxNCwxMSBAQCBzdHJ1Y3Qg bXNnaGRyIHsKIAlpbnQJCSBtc2dfZmxhZ3M7CQkvKiBmbGFncyBvbiByZWNlaXZlZCBtZXNzYWdl ICovCiB9OwogCitzdHJ1Y3QgbW1zZ2hkciB7CisJc3RydWN0IG1zZ2hkcgltc2dfaGRyOwkJLyog bWVzc2FnZSBoZWFkZXIgKi8KKwl1bnNpZ25lZCBpbnQJbXNnX2xlbjsJCS8qIG1lc3NhZ2UgbGVu Z3RoICAqLworfTsKKwogI2RlZmluZQlNU0dfT09CCQkweDEJCS8qIHByb2Nlc3Mgb3V0LW9mLWJh bmQgZGF0YSAqLwogI2RlZmluZQlNU0dfUEVFSwkweDIJCS8qIHBlZWsgYXQgaW5jb21pbmcgbWVz c2FnZSAqLwogI2RlZmluZQlNU0dfRE9OVFJPVVRFCTB4NAkJLyogc2VuZCB3aXRob3V0IHVzaW5n IHJvdXRpbmcgdGFibGVzICovCkBAIC02MTUsMTAgKzYyMCwxMiBAQCBpbnQJbGlzdGVuKGludCwg aW50KTsKIHNzaXplX3QJcmVjdihpbnQsIHZvaWQgKiwgc2l6ZV90LCBpbnQpOwogc3NpemVfdAly ZWN2ZnJvbShpbnQsIHZvaWQgKiwgc2l6ZV90LCBpbnQsIHN0cnVjdCBzb2NrYWRkciAqIF9fcmVz dHJpY3QsIHNvY2tsZW5fdCAqIF9fcmVzdHJpY3QpOwogc3NpemVfdAlyZWN2bXNnKGludCwgc3Ry dWN0IG1zZ2hkciAqLCBpbnQpOworc3NpemVfdAlyZWN2bW1zZyhpbnQsIHN0cnVjdCBtbXNnaGRy ICosIHVuc2lnbmVkIGludCwgaW50KTsKIHNzaXplX3QJc2VuZChpbnQsIGNvbnN0IHZvaWQgKiwg c2l6ZV90LCBpbnQpOwogc3NpemVfdAlzZW5kdG8oaW50LCBjb25zdCB2b2lkICosCiAJICAgIHNp emVfdCwgaW50LCBjb25zdCBzdHJ1Y3Qgc29ja2FkZHIgKiwgc29ja2xlbl90KTsKIHNzaXplX3QJ c2VuZG1zZyhpbnQsIGNvbnN0IHN0cnVjdCBtc2doZHIgKiwgaW50KTsKK3NzaXplX3QJc2VuZG1t c2coaW50LCBjb25zdCBzdHJ1Y3QgbW1zZ2hkciAqLCB1bnNpZ25lZCBpbnQsIGludCk7CiAjaWYg X19CU0RfVklTSUJMRQogaW50CXNlbmRmaWxlKGludCwgaW50LCBvZmZfdCwgc2l6ZV90LCBzdHJ1 Y3Qgc2ZfaGR0ciAqLCBvZmZfdCAqLCBpbnQpOwogaW50CXNldGZpYihpbnQpOwpkaWZmIC0tZ2l0 IGEvc3lzL3N5cy9zeXNjYWxsLmggYi9zeXMvc3lzL3N5c2NhbGwuaAppbmRleCBiYzcyMzQ1Li40 MjFhMTcxIDEwMDY0NAotLS0gYS9zeXMvc3lzL3N5c2NhbGwuaAorKysgYi9zeXMvc3lzL3N5c2Nh bGwuaApAQCAtMyw3ICszLDcgQEAKICAqCiAgKiBETyBOT1QgRURJVC0tIHRoaXMgZmlsZSBpcyBh dXRvbWF0aWNhbGx5IGdlbmVyYXRlZC4KICAqICRGcmVlQlNEJAotICogY3JlYXRlZCBmcm9tIEZy ZWVCU0Q6IGhlYWQvc3lzL2tlcm4vc3lzY2FsbHMubWFzdGVyIDI4NTM4OCAyMDE1LTA3LTExIDE1 OjIyOjExWiBhZHJpYW4gCisgKiBjcmVhdGVkIGZyb20gRnJlZUJTRAogICovCiAKICNkZWZpbmUJ U1lTX3N5c2NhbGwJMApAQCAtNDY3LDQgKzQ2Nyw2IEBACiAjZGVmaW5lCVNZU191dGltZW5zYXQJ NTQ3CiAjZGVmaW5lCVNZU19udW1hX2dldGFmZmluaXR5CTU0OAogI2RlZmluZQlTWVNfbnVtYV9z ZXRhZmZpbml0eQk1NDkKLSNkZWZpbmUJU1lTX01BWFNZU0NBTEwJNTUwCisjZGVmaW5lCVNZU19z ZW5kbW1zZwk1NTAKKyNkZWZpbmUJU1lTX3JlY3ZtbXNnCTU1MQorI2RlZmluZQlTWVNfTUFYU1lT Q0FMTAk1NTIKZGlmZiAtLWdpdCBhL3N5cy9zeXMvc3lzY2FsbC5tayBiL3N5cy9zeXMvc3lzY2Fs bC5tawppbmRleCBmZTJjYjM1Li4yMjllOTE1IDEwMDY0NAotLS0gYS9zeXMvc3lzL3N5c2NhbGwu bWsKKysrIGIvc3lzL3N5cy9zeXNjYWxsLm1rCkBAIC0xLDcgKzEsNyBAQAogIyBGcmVlQlNEIHN5 c3RlbSBjYWxsIG5hbWVzLgogIyBETyBOT1QgRURJVC0tIHRoaXMgZmlsZSBpcyBhdXRvbWF0aWNh bGx5IGdlbmVyYXRlZC4KICMgJEZyZWVCU0QkCi0jIGNyZWF0ZWQgZnJvbSBGcmVlQlNEOiBoZWFk L3N5cy9rZXJuL3N5c2NhbGxzLm1hc3RlciAyODUzODggMjAxNS0wNy0xMSAxNToyMjoxMVogYWRy aWFuIAorIyBjcmVhdGVkIGZyb20gRnJlZUJTRAogTUlBU00gPSAgXAogCXN5c2NhbGwubyBcCiAJ ZXhpdC5vIFwKQEAgLTQxNCw0ICs0MTQsNiBAQCBNSUFTTSA9ICBcCiAJZnV0aW1lbnMubyBcCiAJ dXRpbWVuc2F0Lm8gXAogCW51bWFfZ2V0YWZmaW5pdHkubyBcCi0JbnVtYV9zZXRhZmZpbml0eS5v CisJbnVtYV9zZXRhZmZpbml0eS5vIFwKKwlzZW5kbW1zZy5vIFwKKwlyZWN2bW1zZy5vCmRpZmYg LS1naXQgYS9zeXMvc3lzL3N5c3Byb3RvLmggYi9zeXMvc3lzL3N5c3Byb3RvLmgKaW5kZXggMTQz ZjgxZC4uZTJiMDVhOCAxMDA2NDQKLS0tIGEvc3lzL3N5cy9zeXNwcm90by5oCisrKyBiL3N5cy9z eXMvc3lzcHJvdG8uaApAQCAtMyw3ICszLDcgQEAKICAqCiAgKiBETyBOT1QgRURJVC0tIHRoaXMg ZmlsZSBpcyBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlZC4KICAqICRGcmVlQlNEJAotICogY3JlYXRl ZCBmcm9tIEZyZWVCU0Q6IGhlYWQvc3lzL2tlcm4vc3lzY2FsbHMubWFzdGVyIDI4NTM4OCAyMDE1 LTA3LTExIDE1OjIyOjExWiBhZHJpYW4gCisgKiBjcmVhdGVkIGZyb20gRnJlZUJTRAogICovCiAK ICNpZm5kZWYgX1NZU19TWVNQUk9UT19IXwpAQCAtMTgwMCw2ICsxODAwLDE4IEBAIHN0cnVjdCBu dW1hX3NldGFmZmluaXR5X2FyZ3MgewogCWNoYXIgaWRfbF9bUEFETF8oaWRfdCldOyBpZF90IGlk OyBjaGFyIGlkX3JfW1BBRFJfKGlkX3QpXTsKIAljaGFyIHBvbGljeV9sX1tQQURMXyhjb25zdCBz dHJ1Y3Qgdm1fZG9tYWluX3BvbGljeV9lbnRyeSAqKV07IGNvbnN0IHN0cnVjdCB2bV9kb21haW5f cG9saWN5X2VudHJ5ICogcG9saWN5OyBjaGFyIHBvbGljeV9yX1tQQURSXyhjb25zdCBzdHJ1Y3Qg dm1fZG9tYWluX3BvbGljeV9lbnRyeSAqKV07CiB9Oworc3RydWN0IHNlbmRtbXNnX2FyZ3Mgewor CWNoYXIgc19sX1tQQURMXyhpbnQpXTsgaW50IHM7IGNoYXIgc19yX1tQQURSXyhpbnQpXTsKKwlj aGFyIG1zZ3ZlY19sX1tQQURMXyhzdHJ1Y3QgbW1zZ2hkciAqKV07IHN0cnVjdCBtbXNnaGRyICog bXNndmVjOyBjaGFyIG1zZ3ZlY19yX1tQQURSXyhzdHJ1Y3QgbW1zZ2hkciAqKV07CisJY2hhciB2 bGVuX2xfW1BBRExfKHVuc2lnbmVkIGludCldOyB1bnNpZ25lZCBpbnQgdmxlbjsgY2hhciB2bGVu X3JfW1BBRFJfKHVuc2lnbmVkIGludCldOworCWNoYXIgZmxhZ3NfbF9bUEFETF8oaW50KV07IGlu dCBmbGFnczsgY2hhciBmbGFnc19yX1tQQURSXyhpbnQpXTsKK307CitzdHJ1Y3QgcmVjdm1tc2df YXJncyB7CisJY2hhciBzX2xfW1BBRExfKGludCldOyBpbnQgczsgY2hhciBzX3JfW1BBRFJfKGlu dCldOworCWNoYXIgbXNndmVjX2xfW1BBRExfKHN0cnVjdCBtbXNnaGRyICopXTsgc3RydWN0IG1t c2doZHIgKiBtc2d2ZWM7IGNoYXIgbXNndmVjX3JfW1BBRFJfKHN0cnVjdCBtbXNnaGRyICopXTsK KwljaGFyIHZsZW5fbF9bUEFETF8odW5zaWduZWQgaW50KV07IHVuc2lnbmVkIGludCB2bGVuOyBj aGFyIHZsZW5fcl9bUEFEUl8odW5zaWduZWQgaW50KV07CisJY2hhciBmbGFnc19sX1tQQURMXyhp bnQpXTsgaW50IGZsYWdzOyBjaGFyIGZsYWdzX3JfW1BBRFJfKGludCldOworfTsKIGludAlub3N5 cyhzdHJ1Y3QgdGhyZWFkICosIHN0cnVjdCBub3N5c19hcmdzICopOwogdm9pZAlzeXNfc3lzX2V4 aXQoc3RydWN0IHRocmVhZCAqLCBzdHJ1Y3Qgc3lzX2V4aXRfYXJncyAqKTsKIGludAlzeXNfZm9y ayhzdHJ1Y3QgdGhyZWFkICosIHN0cnVjdCBmb3JrX2FyZ3MgKik7CkBAIC0yMTkwLDYgKzIyMDIs OCBAQCBpbnQJc3lzX2Z1dGltZW5zKHN0cnVjdCB0aHJlYWQgKiwgc3RydWN0IGZ1dGltZW5zX2Fy Z3MgKik7CiBpbnQJc3lzX3V0aW1lbnNhdChzdHJ1Y3QgdGhyZWFkICosIHN0cnVjdCB1dGltZW5z YXRfYXJncyAqKTsKIGludAlzeXNfbnVtYV9nZXRhZmZpbml0eShzdHJ1Y3QgdGhyZWFkICosIHN0 cnVjdCBudW1hX2dldGFmZmluaXR5X2FyZ3MgKik7CiBpbnQJc3lzX251bWFfc2V0YWZmaW5pdHko c3RydWN0IHRocmVhZCAqLCBzdHJ1Y3QgbnVtYV9zZXRhZmZpbml0eV9hcmdzICopOworaW50CXN5 c19zZW5kbW1zZyhzdHJ1Y3QgdGhyZWFkICosIHN0cnVjdCBzZW5kbW1zZ19hcmdzICopOworaW50 CXN5c19yZWN2bW1zZyhzdHJ1Y3QgdGhyZWFkICosIHN0cnVjdCByZWN2bW1zZ19hcmdzICopOwog CiAjaWZkZWYgQ09NUEFUXzQzCiAKQEAgLTI5NDUsNiArMjk1OSw4IEBAIGludAlmcmVlYnNkN19z aG1jdGwoc3RydWN0IHRocmVhZCAqLCBzdHJ1Y3QgZnJlZWJzZDdfc2htY3RsX2FyZ3MgKik7CiAj ZGVmaW5lCVNZU19BVUVfdXRpbWVuc2F0CUFVRV9GVVRJTUVTQVQKICNkZWZpbmUJU1lTX0FVRV9u dW1hX2dldGFmZmluaXR5CUFVRV9OVUxMCiAjZGVmaW5lCVNZU19BVUVfbnVtYV9zZXRhZmZpbml0 eQlBVUVfTlVMTAorI2RlZmluZQlTWVNfQVVFX3NlbmRtbXNnCUFVRV9TRU5ETU1TRworI2RlZmlu ZQlTWVNfQVVFX3JlY3ZtbXNnCUFVRV9SRUNWTU1TRwogCiAjdW5kZWYgUEFEXwogI3VuZGVmIFBB RExfCg== --001a114b3ebce94c900528bb6994-- From owner-freebsd-net@freebsd.org Thu Jan 7 10:14:02 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C095A66EFC for ; Thu, 7 Jan 2016 10:14:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B80871390 for ; Thu, 7 Jan 2016 10:14:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u07ADqua078298 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 12:13:52 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u07ADqua078298 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u07ADpa2078297; Thu, 7 Jan 2016 12:13:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 7 Jan 2016 12:13:51 +0200 From: Konstantin Belousov To: Boris Astardzhiev Cc: Mark Delany , freebsd-net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160107101351.GR3625@kib.kiev.ua> References: <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 10:14:02 -0000 On Thu, Jan 07, 2016 at 11:51:24AM +0200, Boris Astardzhiev wrote: > Hello, > > Here's my implementation of the two system calls. The patch is against HEAD > from a couple of days: Please remove the autogenerated parts of the patch and resend. From owner-freebsd-net@freebsd.org Thu Jan 7 10:28:35 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07F7DA654C9 for ; Thu, 7 Jan 2016 10:28:35 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 851AF1DC9 for ; Thu, 7 Jan 2016 10:28:34 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id f206so91343267wmf.0 for ; Thu, 07 Jan 2016 02:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ea5FvQTkXNOevC7Efecp06WqqsgL3jbl7+hU0JgjV8M=; b=comlir2qr4CJDrfG3BByWXteWjzj5BFMOHcoCWuK0y8fd2nxhCxurHY2SNBKv3K8SC 6PGqlhGPozcIhrEWiMqE5dqBoAQlZQ+TE1fLCFmdFC2skm2iQb2m/xdgUbXFw5N9OYWW mO3hmcTy+k6UL0JB56O2tdaSUGpKRzqryIEXQykXVLTHPDToRls1pDTOCpoHWxk0k1si IndxcJkofy7D4fHb4LqOv/SLtSG7VL58w2xCJ7l6YTFQ1/hKY5hP+wWTw0dloT3alkfX KljzRmIa97OaAXpjvqO+kZKqlQScbG1puokqPrlZMQ7qZYtIS9m13zLvsL7V8Ow+51h2 Qq3w== MIME-Version: 1.0 X-Received: by 10.194.243.103 with SMTP id wx7mr123172211wjc.136.1452162513045; Thu, 07 Jan 2016 02:28:33 -0800 (PST) Received: by 10.28.136.148 with HTTP; Thu, 7 Jan 2016 02:28:32 -0800 (PST) In-Reply-To: <20160107101351.GR3625@kib.kiev.ua> References: <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107101351.GR3625@kib.kiev.ua> Date: Thu, 7 Jan 2016 12:28:32 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: Konstantin Belousov Cc: Mark Delany , freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=089e01493c12bf93910528bbeec6 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 10:28:35 -0000 --089e01493c12bf93910528bbeec6 Content-Type: text/plain; charset=UTF-8 > Please remove the autogenerated parts of the patch and resend. On Thu, Jan 7, 2016 at 12:13 PM, Konstantin Belousov wrote: > On Thu, Jan 07, 2016 at 11:51:24AM +0200, Boris Astardzhiev wrote: > > Hello, > > > > Here's my implementation of the two system calls. The patch is against > HEAD > > from a couple of days: > Please remove the autogenerated parts of the patch and resend. > --089e01493c12bf93910528bbeec6 Content-Type: text/plain; charset=US-ASCII; name="sendrecvmmsg.diff" Content-Disposition: attachment; filename="sendrecvmmsg.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ij441b7t0 ZGlmZiAtLWdpdCBhL2xpYi9saWJjL2luY2x1ZGUvbGliY19wcml2YXRlLmggYi9saWIvbGliYy9p bmNsdWRlL2xpYmNfcHJpdmF0ZS5oCmluZGV4IDVjYWY5YTMuLjdlMmE5MDIgMTAwNjQ0Ci0tLSBh L2xpYi9saWJjL2luY2x1ZGUvbGliY19wcml2YXRlLmgKKysrIGIvbGliL2xpYmMvaW5jbHVkZS9s aWJjX3ByaXZhdGUuaApAQCAtMjAwLDggKzIwMCwxMCBAQCBlbnVtIHsKIAlJTlRFUlBPU19wc2Vs ZWN0LAogCUlOVEVSUE9TX3JlY3Zmcm9tLAogCUlOVEVSUE9TX3JlY3Ztc2csCisJSU5URVJQT1Nf cmVjdm1tc2csCiAJSU5URVJQT1Nfc2VsZWN0LAogCUlOVEVSUE9TX3NlbmRtc2csCisJSU5URVJQ T1Nfc2VuZG1tc2csCiAJSU5URVJQT1Nfc2VuZHRvLAogCUlOVEVSUE9TX3NldGNvbnRleHQsCiAJ SU5URVJQT1Nfc2lnYWN0aW9uLApAQCAtMjg5LDYgKzI5MSw3IEBAIHN0cnVjdCBmZF9zZXQ7CiBz dHJ1Y3QgaW92ZWM7CiBzdHJ1Y3Qga2V2ZW50Owogc3RydWN0IG1zZ2hkcjsKK3N0cnVjdCBtbXNn aGRyOwogc3RydWN0IHBvbGxmZDsKIHN0cnVjdCBydXNhZ2U7CiBzdHJ1Y3Qgc2lnYWN0aW9uOwpA QCAtMzM0LDkgKzMzNywxMSBAQCBfX3NzaXplX3QJX19zeXNfcmVjdihpbnQsIHZvaWQgKiwgX19z aXplX3QsIGludCk7CiBfX3NzaXplX3QJX19zeXNfcmVjdmZyb20oaW50LCB2b2lkICosIF9fc2l6 ZV90LCBpbnQsIHN0cnVjdCBzb2NrYWRkciAqLAogCQkgICAgX19zb2NrbGVuX3QgKik7CiBfX3Nz aXplX3QJX19zeXNfcmVjdm1zZyhpbnQsIHN0cnVjdCBtc2doZHIgKiwgaW50KTsKK19fc3NpemVf dAlfX3N5c19yZWN2bW1zZyhpbnQsIHN0cnVjdCBtbXNnaGRyICosIHVuc2lnbmVkIGludCwgaW50 KTsKIGludAkJX19zeXNfc2VsZWN0KGludCwgc3RydWN0IGZkX3NldCAqLCBzdHJ1Y3QgZmRfc2V0 ICosCiAJCSAgICBzdHJ1Y3QgZmRfc2V0ICosIHN0cnVjdCB0aW1ldmFsICopOwogX19zc2l6ZV90 CV9fc3lzX3NlbmRtc2coaW50LCBjb25zdCBzdHJ1Y3QgbXNnaGRyICosIGludCk7CitfX3NzaXpl X3QJX19zeXNfc2VuZG1tc2coaW50LCBjb25zdCBzdHJ1Y3QgbW1zZ2hkciAqLCB1bnNpZ25lZCBp bnQsIGludCk7CiBfX3NzaXplX3QJX19zeXNfc2VuZHRvKGludCwgY29uc3Qgdm9pZCAqLCBfX3Np emVfdCwgaW50LAogCQkgICAgY29uc3Qgc3RydWN0IHNvY2thZGRyICosIF9fc29ja2xlbl90KTsK IGludAkJX19zeXNfc2V0Y29udGV4dChjb25zdCBzdHJ1Y3QgX191Y29udGV4dCAqKTsKZGlmZiAt LWdpdCBhL2xpYi9saWJjL2luY2x1ZGUvbmFtZXNwYWNlLmggYi9saWIvbGliYy9pbmNsdWRlL25h bWVzcGFjZS5oCmluZGV4IDczOWQ3YjEuLmM5NTgyOWUgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL2lu Y2x1ZGUvbmFtZXNwYWNlLmgKKysrIGIvbGliL2xpYmMvaW5jbHVkZS9uYW1lc3BhY2UuaApAQCAt MjA4LDYgKzIwOCw3IEBACiAjZGVmaW5lCQlyZWFkdgkJCQlfcmVhZHYKICNkZWZpbmUJCXJlY3Zm cm9tCQkJX3JlY3Zmcm9tCiAjZGVmaW5lCQlyZWN2bXNnCQkJCV9yZWN2bXNnCisjZGVmaW5lCQly ZWN2bW1zZwkJCV9yZWN2bW1zZwogI2RlZmluZQkJc2VsZWN0CQkJCV9zZWxlY3QKICNkZWZpbmUJ CXNlbV9jbG9zZQkJCV9zZW1fY2xvc2UKICNkZWZpbmUJCXNlbV9kZXN0cm95CQkJX3NlbV9kZXN0 cm95CkBAIC0yMjAsNiArMjIxLDcgQEAKICNkZWZpbmUJCXNlbV91bmxpbmsJCQlfc2VtX3VubGlu awogI2RlZmluZQkJc2VtX3dhaXQJCQlfc2VtX3dhaXQKICNkZWZpbmUJCXNlbmRtc2cJCQkJX3Nl bmRtc2cKKyNkZWZpbmUJCXNlbmRtbXNnCQkJX3NlbmRtbXNnCiAjZGVmaW5lCQlzZW5kdG8JCQkJ X3NlbmR0bwogI2RlZmluZQkJc2V0c29ja29wdAkJCV9zZXRzb2Nrb3B0CiAvKiNkZWZpbmUJCXNp Z2FjdGlvbgkJCV9zaWdhY3Rpb24qLwpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvaW5jbHVkZS91bi1u YW1lc3BhY2UuaCBiL2xpYi9saWJjL2luY2x1ZGUvdW4tbmFtZXNwYWNlLmgKaW5kZXggZjMxZmE3 YS4uMDIzMzM0OCAxMDA2NDQKLS0tIGEvbGliL2xpYmMvaW5jbHVkZS91bi1uYW1lc3BhY2UuaAor KysgYi9saWIvbGliYy9pbmNsdWRlL3VuLW5hbWVzcGFjZS5oCkBAIC0xODksNiArMTg5LDcgQEAK ICN1bmRlZgkJcmVhZHYKICN1bmRlZgkJcmVjdmZyb20KICN1bmRlZgkJcmVjdm1zZworI3VuZGVm CQlyZWN2bW1zZwogI3VuZGVmCQlzZWxlY3QKICN1bmRlZgkJc2VtX2Nsb3NlCiAjdW5kZWYJCXNl bV9kZXN0cm95CkBAIC0yMDEsNiArMjAyLDcgQEAKICN1bmRlZgkJc2VtX3VubGluawogI3VuZGVm CQlzZW1fd2FpdAogI3VuZGVmCQlzZW5kbXNnCisjdW5kZWYJCXNlbmRtbXNnCiAjdW5kZWYJCXNl bmR0bwogI3VuZGVmCQlzZXRzb2Nrb3B0CiAjdW5kZWYJCXNpZ2FjdGlvbgpkaWZmIC0tZ2l0IGEv bGliL2xpYmMvc3lzL01ha2VmaWxlLmluYyBiL2xpYi9saWJjL3N5cy9NYWtlZmlsZS5pbmMKaW5k ZXggZTRmZTFiMi4uMWMwOWZjZSAxMDA2NDQKLS0tIGEvbGliL2xpYmMvc3lzL01ha2VmaWxlLmlu YworKysgYi9saWIvbGliYy9zeXMvTWFrZWZpbGUuaW5jCkBAIC00OSw4ICs0OSwxMCBAQCBJTlRF UlBPU0VEID0gXAogCXJlYWR2IFwKIAlyZWN2ZnJvbSBcCiAJcmVjdm1zZyBcCisJcmVjdm1tc2cg XAogCXNlbGVjdCBcCiAJc2VuZG1zZyBcCisJc2VuZG1tc2cgXAogCXNlbmR0byBcCiAJc2V0Y29u dGV4dCBcCiAJc2lncHJvY21hc2sgXApkaWZmIC0tZ2l0IGEvbGliL2xpYmMvc3lzL1N5bWJvbC5t YXAgYi9saWIvbGliYy9zeXMvU3ltYm9sLm1hcAppbmRleCA3YjMyNTdjLi42Y2MzYzZlIDEwMDY0 NAotLS0gYS9saWIvbGliYy9zeXMvU3ltYm9sLm1hcAorKysgYi9saWIvbGliYy9zeXMvU3ltYm9s Lm1hcApAQCAtMjIwLDYgKzIyMCw3IEBAIEZCU0RfMS4wIHsKIAlyZWJvb3Q7CiAJcmVjdmZyb207 CiAJcmVjdm1zZzsKKwlyZWN2bW1zZzsKIAlyZW5hbWU7CiAJcmV2b2tlOwogCXJmb3JrOwpAQCAt MjQwLDYgKzI0MSw3IEBAIEZCU0RfMS4wIHsKIAlzZW1zeXM7CiAJc2VuZGZpbGU7CiAJc2VuZG1z ZzsKKwlzZW5kbW1zZzsKIAlzZW5kdG87CiAJc2V0YXVkaXQ7CiAJc2V0YXVkaXRfYWRkcjsKQEAg LTg1MSw2ICs4NTMsOCBAQCBGQlNEcHJpdmF0ZV8xLjAgewogCV9fc3lzX3JlY3Zmcm9tOwogCV9y ZWN2bXNnOwogCV9fc3lzX3JlY3Ztc2c7CisJX3JlY3ZtbXNnOworCV9fc3lzX3JlY3ZtbXNnOwog CV9yZW5hbWU7CiAJX19zeXNfcmVuYW1lOwogCV9yZXZva2U7CkBAIC04OTEsNiArODk1LDggQEAg RkJTRHByaXZhdGVfMS4wIHsKIAlfX3N5c19zZW5kZmlsZTsKIAlfc2VuZG1zZzsKIAlfX3N5c19z ZW5kbXNnOworCV9zZW5kbW1zZzsKKwlfX3N5c19zZW5kbW1zZzsKIAlfc2VuZHRvOwogCV9fc3lz X3NlbmR0bzsKIAlfc2V0YXVkaXQ7CmRpZmYgLS1naXQgYS9saWIvbGliYy9zeXMvaW50ZXJwb3Np bmdfdGFibGUuYyBiL2xpYi9saWJjL3N5cy9pbnRlcnBvc2luZ190YWJsZS5jCmluZGV4IDA4ZGZi YjEuLmM4NjZhNzUgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL3N5cy9pbnRlcnBvc2luZ190YWJsZS5j CisrKyBiL2xpYi9saWJjL3N5cy9pbnRlcnBvc2luZ190YWJsZS5jCkBAIC01Niw4ICs1NiwxMCBA QCBpbnRlcnBvc19mdW5jX3QgX19saWJjX2ludGVycG9zaW5nW0lOVEVSUE9TX01BWF0gPSB7CiAJ U0xPVChyZWFkdiwgX19zeXNfcmVhZHYpLAogCVNMT1QocmVjdmZyb20sIF9fc3lzX3JlY3Zmcm9t KSwKIAlTTE9UKHJlY3Ztc2csIF9fc3lzX3JlY3Ztc2cpLAorCVNMT1QocmVjdm1tc2csIF9fc3lz X3JlY3ZtbXNnKSwKIAlTTE9UKHNlbGVjdCwgX19zeXNfc2VsZWN0KSwKIAlTTE9UKHNlbmRtc2cs IF9fc3lzX3NlbmRtc2cpLAorCVNMT1Qoc2VuZG1tc2csIF9fc3lzX3NlbmRtbXNnKSwKIAlTTE9U KHNlbmR0bywgX19zeXNfc2VuZHRvKSwKIAlTTE9UKHNldGNvbnRleHQsIF9fc3lzX3NldGNvbnRl eHQpLAogCVNMT1Qoc2lnYWN0aW9uLCBfX3N5c19zaWdhY3Rpb24pLApkaWZmIC0tZ2l0IGEvbGli L2xpYmMvc3lzL3JlY3ZtbXNnLmMgYi9saWIvbGliYy9zeXMvcmVjdm1tc2cuYwpuZXcgZmlsZSBt b2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi5iYmIwNTg4Ci0tLSAvZGV2L251bGwKKysrIGIvbGli L2xpYmMvc3lzL3JlY3ZtbXNnLmMKQEAgLTAsMCArMSw0NyBAQAorLyoKKyAqIENvcHlyaWdodCAo YykgMjAxNiBCb3JpcyBBc3RhcmR6aGlldiwgU21hcnRjb20tQnVsZ2FyaWEgQUQKKyAqIEFsbCBy aWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2Ug YW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBw ZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBt ZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhl IGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlKHMpLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9u cyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGFzCisgKiAgICB0aGUgZmlyc3QgbGluZXMg b2YgdGhpcyBmaWxlIHVubW9kaWZpZWQgb3RoZXIgdGhhbiB0aGUgcG9zc2libGUKKyAqICAgIGFk ZGl0aW9uIG9mIG9uZSBvciBtb3JlIGNvcHlyaWdodCBub3RpY2VzLgorICogMi4gUmVkaXN0cmli dXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQK KyAqICAgIG5vdGljZShzKSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dp bmcgZGlzY2xhaW1lciBpbgorICogICAgdGhlIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1h dGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZQorICogICAgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRI SVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIENPUFlSSUdIVCBIT0xERVIoUykgYGBBUyBJ UycnIEFORCBBTlkKKyAqIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcs IEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hB TlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIKKyAqIFBVUlBPU0UgQVJFIERJ U0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQ09QWVJJR0hUIEhPTERFUihTKSBCRQor ICogTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwg RVhFTVBMQVJZLCBPUgorICogQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBO T1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YKKyAqIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VS VklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUgorICogQlVTSU5FU1MgSU5U RVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFks CisgKiBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUIChJTkNM VURJTkcgTkVHTElHRU5DRQorICogT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VU IE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwKKyAqIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUg UE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCisgKi8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5o PgorX19GQlNESUQoIiRGcmVlQlNEJCIpOworCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5j bHVkZSA8c3lzL3N5c2NhbGwuaD4KKyNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+CisjaW5jbHVkZSAi bGliY19wcml2YXRlLmgiCisKK19fd2Vha19yZWZlcmVuY2UoX19zeXNfcmVjdm1tc2csIF9fcmVj dm1tc2cpOworCisjcHJhZ21hIHdlYWsgcmVjdm1tc2cKK3NzaXplX3QKK3JlY3ZtbXNnKGludCBz LCBzdHJ1Y3QgbW1zZ2hkciAqbXNndmVjLCB1bnNpZ25lZCBpbnQgdmxlbiwgaW50IGZsYWdzKQor eworCisJcmV0dXJuICgoKGludCAoKikoaW50LCBzdHJ1Y3QgbW1zZ2hkciAqLCBpbnQsIGludCkp CisJICAgIF9fbGliY19pbnRlcnBvc2luZ1tJTlRFUlBPU19yZWN2bW1zZ10pKHMsIG1zZ3ZlYywg dmxlbiwgZmxhZ3MpKTsKK30KZGlmZiAtLWdpdCBhL2xpYi9saWJjL3N5cy9zZW5kbW1zZy5jIGIv bGliL2xpYmMvc3lzL3NlbmRtbXNnLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAw MC4uMzk4ZjljYQotLS0gL2Rldi9udWxsCisrKyBiL2xpYi9saWJjL3N5cy9zZW5kbW1zZy5jCkBA IC0wLDAgKzEsNDcgQEAKKy8qCisgKiBDb3B5cmlnaHQgKGMpIDIwMTYgQm9yaXMgQXN0YXJkemhp ZXYsIFNtYXJ0Y29tLUJ1bGdhcmlhIEFECisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAq IFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGgg b3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQg dGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRp b25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAg IG5vdGljZShzKSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lciBhcworICogICAgdGhlIGZpcnN0IGxpbmVzIG9mIHRoaXMgZmlsZSB1bm1vZGlmaWVk IG90aGVyIHRoYW4gdGhlIHBvc3NpYmxlCisgKiAgICBhZGRpdGlvbiBvZiBvbmUgb3IgbW9yZSBj b3B5cmlnaHQgbm90aWNlcy4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBt dXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UocyksIHRoaXMg bGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4KKyAqICAg IHRoZSBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0 aGUKKyAqICAgIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVE IEJZIFRIRSBDT1BZUklHSFQgSE9MREVSKFMpIGBgQVMgSVMnJyBBTkQgQU5ZCisgKiBFWFBSRVNT IE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRI RQorICogSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBG T1IgQSBQQVJUSUNVTEFSCisgKiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQg U0hBTEwgVEhFIENPUFlSSUdIVCBIT0xERVIoUykgQkUKKyAqIExJQUJMRSBGT1IgQU5ZIERJUkVD VCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IKKyAqIENPTlNF UVVFTlRJQUwgREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVN RU5UIE9GCisgKiBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFU QSwgT1IgUFJPRklUUzsgT1IKKyAqIEJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVT RUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLAorICogV0hFVEhFUiBJTiBDT05UUkFD VCwgU1RSSUNUIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UKKyAqIE9S IE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09G VFdBUkUsCisgKiBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFN QUdFLgorICovCisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRCQi KTsKKworI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9zeXNjYWxsLmg+Cisj aW5jbHVkZSA8c3lzL3NvY2tldC5oPgorI2luY2x1ZGUgImxpYmNfcHJpdmF0ZS5oIgorCitfX3dl YWtfcmVmZXJlbmNlKF9fc3lzX3NlbmRtbXNnLCBfX3NlbmRtbXNnKTsKKworI3ByYWdtYSB3ZWFr IHNlbmRtbXNnCitzc2l6ZV90CitzZW5kbW1zZyhpbnQgcywgY29uc3Qgc3RydWN0IG1tc2doZHIg Km1zZ3ZlYywgdW5zaWduZWQgaW50IHZsZW4sIGludCBmbGFncykKK3sKKworCXJldHVybiAoKChp bnQgKCopKGludCwgY29uc3Qgc3RydWN0IG1tc2doZHIgKiwgaW50LCBpbnQpKQorCSAgICBfX2xp YmNfaW50ZXJwb3NpbmdbSU5URVJQT1Nfc2VuZG1tc2ddKShzLCBtc2d2ZWMsIHZsZW4sIGZsYWdz KSk7Cit9CmRpZmYgLS1naXQgYS9zeXMvYnNtL2F1ZGl0X2tldmVudHMuaCBiL3N5cy9ic20vYXVk aXRfa2V2ZW50cy5oCmluZGV4IDNjMTZjNzMuLjJmYzg4N2EgMTAwNjQ0Ci0tLSBhL3N5cy9ic20v YXVkaXRfa2V2ZW50cy5oCisrKyBiL3N5cy9ic20vYXVkaXRfa2V2ZW50cy5oCkBAIC02MTEsNiAr NjExLDggQEAKICNkZWZpbmUJQVVFX0JJTkRBVAkJNDMyMDcJLyogVHJ1c3RlZEJTRC4gKi8KICNk ZWZpbmUJQVVFX0NPTk5FQ1RBVAkJNDMyMDgJLyogVHJ1c3RlZEJTRC4gKi8KICNkZWZpbmUJQVVF X0NIRkxBR1NBVAkJNDMyMDkJLyogRnJlZUJTRC1zcGVjaWZpYy4gKi8KKyNkZWZpbmUJQVVFX1NF TkRNTVNHCQk0MzIxMAorI2RlZmluZQlBVUVfUkVDVk1NU0cJCTQzMjExCiAKIC8qCiAgKiBEYXJ3 aW4gQlNNIHVzZXMgYSBudW1iZXIgb2YgQVVFX09fKiBkZWZpbml0aW9ucywgd2hpY2ggYXJlIGFs aWFzZWQgdG8gdGhlCmRpZmYgLS1naXQgYS9zeXMva2Vybi9zeXNjYWxscy5tYXN0ZXIgYi9zeXMv a2Vybi9zeXNjYWxscy5tYXN0ZXIKaW5kZXggNmU2ZmIzOC4uNjE5MDg5NSAxMDA2NDQKLS0tIGEv c3lzL2tlcm4vc3lzY2FsbHMubWFzdGVyCisrKyBiL3N5cy9rZXJuL3N5c2NhbGxzLm1hc3RlcgpA QCAtOTk0LDYgKzk5NCwxMCBAQAogNTQ5CUFVRV9OVUxMCVNURAl7IGludCBudW1hX3NldGFmZmlu aXR5KGNwdXdoaWNoX3Qgd2hpY2gsIFwKIAkJCQkgICAgaWRfdCBpZCwgXAogCQkJCSAgICBjb25z dCBzdHJ1Y3Qgdm1fZG9tYWluX3BvbGljeV9lbnRyeSAqcG9saWN5KTsgfQorNTUwCUFVRV9TRU5E TU1TRwlTVEQJeyBpbnQgc2VuZG1tc2coaW50IHMsIHN0cnVjdCBtbXNnaGRyICptc2d2ZWMsXAor CQkJCSAgICB1bnNpZ25lZCBpbnQgdmxlbiwgaW50IGZsYWdzKTsgfQorNTUxCUFVRV9SRUNWTU1T RwlTVEQJeyBpbnQgcmVjdm1tc2coaW50IHMsIHN0cnVjdCBtbXNnaGRyICptc2d2ZWMsXAorCQkJ CSAgICB1bnNpZ25lZCBpbnQgdmxlbiwgaW50IGZsYWdzKTsgfQogCiA7IFBsZWFzZSBjb3B5IGFu eSBhZGRpdGlvbnMgYW5kIGNoYW5nZXMgdG8gdGhlIGZvbGxvd2luZyBjb21wYXRhYmlsaXR5IHRh YmxlczoKIDsgc3lzL2NvbXBhdC9mcmVlYnNkMzIvc3lzY2FsbHMubWFzdGVyCmRpZmYgLS1naXQg YS9zeXMva2Vybi91aXBjX3N5c2NhbGxzLmMgYi9zeXMva2Vybi91aXBjX3N5c2NhbGxzLmMKaW5k ZXggYzMzYTJjZi4uNzM1NGI0ZiAxMDA2NDQKLS0tIGEvc3lzL2tlcm4vdWlwY19zeXNjYWxscy5j CisrKyBiL3N5cy9rZXJuL3VpcGNfc3lzY2FsbHMuYwpAQCAtMTAzOCw2ICsxMDM4LDgyIEBAIHN5 c19zZW5kbXNnKHRkLCB1YXApCiB9CiAKIGludAorc3lzX3NlbmRtbXNnKHRkLCB1YXApCisJc3Ry dWN0IHRocmVhZCAqdGQ7CisJc3RydWN0IHNlbmRtbXNnX2FyZ3MgLyogeworCQlpbnQJczsKKwkJ c3RydWN0IG1tc2doZHIJKm1zZ3ZlYzsKKwkJdW5zaWduZWQgaW50CXZsZW47CisJCWludAlmbGFn czsKKwl9ICovICp1YXA7Cit7CisJc3RydWN0IG1tc2doZHIgKnZlYywgKm1tcDsKKwlzdHJ1Y3Qg bXNnaGRyICptcCwgbXNnOworCXN0cnVjdCBpb3ZlYyAqaW92OworCXVuc2lnbmVkIGludCB2bGVu LCBsZW47CisJaW50IGksIHNlbnQgPSAwLCBlcnJvcjsKKwlzdHJ1Y3Qgc29ja2V0ICpzbyA9IE5V TEw7CisJc3RydWN0IGZpbGUgKmZwOworCWNhcF9yaWdodHNfdCByaWdodHM7CisKKwlpZiAoZmdl dCh0ZCwgdWFwLT5zLCBjYXBfcmlnaHRzX2luaXQoJnJpZ2h0cywgQ0FQX1NFTkQpLCAmZnApICE9 IDApCisJCXJldHVybiAoRUJBREYpOworCisJc28gPSBmcC0+Zl9kYXRhOworCisJdmxlbiA9IHVh cC0+dmxlbjsKKwlpZiAodmxlbiA+IFVJT19NQVhJT1YpCisJCXZsZW4gPSBVSU9fTUFYSU9WOwor CisJbGVuID0gdmxlbiAqIHNpemVvZigqdWFwLT5tc2d2ZWMpOworCXZlYyA9IG1hbGxvYyhsZW4s IE1fVEVNUCwgTV9XQUlUT0spOworCisJZXJyb3IgPSBjb3B5aW4odWFwLT5tc2d2ZWMsIHZlYywg bGVuKTsKKwlpZiAoZXJyb3IgIT0gMCkKKwkJZ290byBvdXQ7CisKKwlmb3IgKGkgPSAwOyBpIDwg dmxlbjsgaSsrKSB7CisJCW1tcCA9ICZ2ZWNbaV07CisJCW1wID0gJm1tcC0+bXNnX2hkcjsKKwkJ bXNnID0gKm1wOworCisJCWVycm9yID0gY29weWluaW92KG1zZy5tc2dfaW92LCBtc2cubXNnX2lv dmxlbiwgJmlvdiwgRU1TR1NJWkUpOworCQlpZiAoZXJyb3IgIT0gMCkKKwkJCWdvdG8gb3V0Owor CisJCW1zZy5tc2dfaW92ID0gaW92OworI2lmZGVmIENPTVBBVF9PTERTT0NLCisJCW1zZy5tc2df ZmxhZ3MgPSAwOworI2VuZGlmCisJCWVycm9yID0gc2VuZGl0KHRkLCB1YXAtPnMsICZtc2csIHVh cC0+ZmxhZ3MpOworCQlmcmVlKGlvdiwgTV9JT1YpOworCQlpZiAoZXJyb3IgIT0gMCkKKwkJCWdv dG8gb3V0OworCisJCWVycm9yID0gY29weW91dCgmdGQtPnRkX3JldHZhbFswXSwgJnVhcC0+bXNn dmVjW2ldLm1zZ19sZW4sCisJCSAgICBzaXplb2YodGQtPnRkX3JldHZhbFswXSkpOworCQlpZiAo ZXJyb3IgIT0gMCkKKwkJCWdvdG8gb3V0OworCisJCXNlbnQrKzsKKwl9CisKKwl0ZC0+dGRfcmV0 dmFsWzBdID0gc2VudDsKKworb3V0OgorCWlmIChlcnJvciAhPSAwICYmIHNlbnQgIT0gMCAmJiBz ZW50ICE9IHZsZW4pIHsKKwkJc28tPnNvX2Vycm9yID0gZXJyb3I7CisJCWVycm9yID0gMDsKKwkJ dGQtPnRkX3JldHZhbFswXSA9IHNlbnQ7CisJfQorCisJZmRyb3AoZnAsIHRkKTsKKworCWZyZWUo dmVjLCBNX1RFTVApOworCXJldHVybiAoZXJyb3IpOworfQorCitpbnQKIGtlcm5fcmVjdml0KHRk LCBzLCBtcCwgZnJvbXNlZywgY29udHJvbHApCiAJc3RydWN0IHRocmVhZCAqdGQ7CiAJaW50IHM7 CkBAIC0xMzYzLDYgKzE0MzksOTEgQEAgc3lzX3JlY3Ztc2codGQsIHVhcCkKIAlyZXR1cm4gKGVy cm9yKTsKIH0KIAoraW50CitzeXNfcmVjdm1tc2codGQsIHVhcCkKKwlzdHJ1Y3QgdGhyZWFkICp0 ZDsKKwlzdHJ1Y3QgcmVjdm1tc2dfYXJncyAvKiB7CisJCWludAlzOworCQlzdHJ1Y3QgbW1zZ2hk cgkqbXNndmVjOworCQl1bnNpZ25lZCBpbnQJdmxlbjsKKwkJaW50CWZsYWdzOworCX0gKi8gKnVh cDsKK3sKKwlzdHJ1Y3QgbW1zZ2hkciAqdmVjLCAqbW1wOworCXN0cnVjdCBtc2doZHIgKm1wLCBt c2c7CisJc3RydWN0IGlvdmVjICp1aW92LCAqaW92OworCXVuc2lnbmVkIGludCB2bGVuLCBsZW47 CisJaW50IGksIHJjdmQgPSAwLCBlcnJvcjsKKwlzdHJ1Y3Qgc29ja2V0ICpzbyA9IE5VTEw7CisJ c3RydWN0IGZpbGUgKmZwOworCWNhcF9yaWdodHNfdCByaWdodHM7CisKKwlpZiAoZmdldCh0ZCwg dWFwLT5zLCBjYXBfcmlnaHRzX2luaXQoJnJpZ2h0cywgQ0FQX1JFQ1YpLCAmZnApICE9IDApCisJ CXJldHVybiAoRUJBREYpOworCisJc28gPSBmcC0+Zl9kYXRhOworCisJdmxlbiA9IHVhcC0+dmxl bjsKKwlpZiAodmxlbiA+IFVJT19NQVhJT1YpCisJCXZsZW4gPSBVSU9fTUFYSU9WOworCisJbGVu ID0gdmxlbiAqIHNpemVvZigqdWFwLT5tc2d2ZWMpOworCXZlYyA9IG1hbGxvYyhsZW4sIE1fVEVN UCwgTV9XQUlUT0spOworCisJZXJyb3IgPSBjb3B5aW4odWFwLT5tc2d2ZWMsIHZlYywgbGVuKTsK KwlpZiAoZXJyb3IgIT0gMCkKKwkJZ290byBvdXQ7CisKKwlmb3IgKGkgPSAwOyBpIDwgdmxlbjsg aSsrKSB7CisJCW1tcCA9ICZ2ZWNbaV07CisJCW1wID0gJm1tcC0+bXNnX2hkcjsKKwkJbXNnID0g Km1wOworCisJCWVycm9yID0gY29weWluaW92KG1zZy5tc2dfaW92LCBtc2cubXNnX2lvdmxlbiwg JmlvdiwgRU1TR1NJWkUpOworCQlpZiAoZXJyb3IgIT0gMCkKKwkJCWdvdG8gb3V0OworCisJCW1z Zy5tc2dfZmxhZ3MgPSB1YXAtPmZsYWdzOworI2lmZGVmIENPTVBBVF9PTERTT0NLCisJCW1zZy5t c2dfZmxhZ3MgJj0gfk1TR19DT01QQVQ7CisjZW5kaWYKKwkJdWlvdiA9IG1zZy5tc2dfaW92Owor CQltc2cubXNnX2lvdiA9IGlvdjsKKworCQllcnJvciA9IHJlY3ZpdCh0ZCwgdWFwLT5zLCAmbXNn LCBOVUxMKTsKKwkJaWYgKGVycm9yID09IDApIHsKKwkJCW1zZy5tc2dfaW92ID0gdWlvdjsKKwkJ CWVycm9yID0gY29weW91dCgmbXNnLCAmdWFwLT5tc2d2ZWNbaV0ubXNnX2hkciwgc2l6ZW9mKG1z ZykpOworCQkJaWYgKGVycm9yICE9IDApIHsKKwkJCQlmcmVlKGlvdiwgTV9JT1YpOworCQkJCWdv dG8gb3V0OworCQkJfQorCQkJZXJyb3IgPSBjb3B5b3V0KCZ0ZC0+dGRfcmV0dmFsWzBdLCAmdWFw LT5tc2d2ZWNbaV0ubXNnX2xlbiwKKwkJCSAgICBzaXplb2YodGQtPnRkX3JldHZhbFswXSkpOwor CQkJaWYgKGVycm9yICE9IDApIHsKKwkJCQlmcmVlKGlvdiwgTV9JT1YpOworCQkJCWdvdG8gb3V0 OworCQkJfQorCQl9CisJCWZyZWUoaW92LCBNX0lPVik7CisJCXJjdmQrKzsKKwl9CisKKwl0ZC0+ dGRfcmV0dmFsWzBdID0gcmN2ZDsKKworb3V0OgorCWlmIChlcnJvciAhPSAwICYmIHJjdmQgIT0g MCAmJiByY3ZkICE9IHZsZW4pIHsKKwkJc28tPnNvX2Vycm9yID0gZXJyb3I7CisJCWVycm9yID0g MDsKKwkJdGQtPnRkX3JldHZhbFswXSA9IHJjdmQ7CisJfQorCisJZmRyb3AoZnAsIHRkKTsKKwor CWZyZWUodmVjLCBNX1RFTVApOworCXJldHVybiAoZXJyb3IpOworfQorCiAvKiBBUkdTVVNFRCAq LwogaW50CiBzeXNfc2h1dGRvd24odGQsIHVhcCkKZGlmZiAtLWdpdCBhL3N5cy9zeXMvc29ja2V0 LmggYi9zeXMvc3lzL3NvY2tldC5oCmluZGV4IDE4ZTJkZTEuLmQzNTJjZDIgMTAwNjQ0Ci0tLSBh L3N5cy9zeXMvc29ja2V0LmgKKysrIGIvc3lzL3N5cy9zb2NrZXQuaApAQCAtNDE0LDYgKzQxNCwx MSBAQCBzdHJ1Y3QgbXNnaGRyIHsKIAlpbnQJCSBtc2dfZmxhZ3M7CQkvKiBmbGFncyBvbiByZWNl aXZlZCBtZXNzYWdlICovCiB9OwogCitzdHJ1Y3QgbW1zZ2hkciB7CisJc3RydWN0IG1zZ2hkcglt c2dfaGRyOwkJLyogbWVzc2FnZSBoZWFkZXIgKi8KKwl1bnNpZ25lZCBpbnQJbXNnX2xlbjsJCS8q IG1lc3NhZ2UgbGVuZ3RoICAqLworfTsKKwogI2RlZmluZQlNU0dfT09CCQkweDEJCS8qIHByb2Nl c3Mgb3V0LW9mLWJhbmQgZGF0YSAqLwogI2RlZmluZQlNU0dfUEVFSwkweDIJCS8qIHBlZWsgYXQg aW5jb21pbmcgbWVzc2FnZSAqLwogI2RlZmluZQlNU0dfRE9OVFJPVVRFCTB4NAkJLyogc2VuZCB3 aXRob3V0IHVzaW5nIHJvdXRpbmcgdGFibGVzICovCkBAIC02MTUsMTAgKzYyMCwxMiBAQCBpbnQJ bGlzdGVuKGludCwgaW50KTsKIHNzaXplX3QJcmVjdihpbnQsIHZvaWQgKiwgc2l6ZV90LCBpbnQp Owogc3NpemVfdAlyZWN2ZnJvbShpbnQsIHZvaWQgKiwgc2l6ZV90LCBpbnQsIHN0cnVjdCBzb2Nr YWRkciAqIF9fcmVzdHJpY3QsIHNvY2tsZW5fdCAqIF9fcmVzdHJpY3QpOwogc3NpemVfdAlyZWN2 bXNnKGludCwgc3RydWN0IG1zZ2hkciAqLCBpbnQpOworc3NpemVfdAlyZWN2bW1zZyhpbnQsIHN0 cnVjdCBtbXNnaGRyICosIHVuc2lnbmVkIGludCwgaW50KTsKIHNzaXplX3QJc2VuZChpbnQsIGNv bnN0IHZvaWQgKiwgc2l6ZV90LCBpbnQpOwogc3NpemVfdAlzZW5kdG8oaW50LCBjb25zdCB2b2lk ICosCiAJICAgIHNpemVfdCwgaW50LCBjb25zdCBzdHJ1Y3Qgc29ja2FkZHIgKiwgc29ja2xlbl90 KTsKIHNzaXplX3QJc2VuZG1zZyhpbnQsIGNvbnN0IHN0cnVjdCBtc2doZHIgKiwgaW50KTsKK3Nz aXplX3QJc2VuZG1tc2coaW50LCBjb25zdCBzdHJ1Y3QgbW1zZ2hkciAqLCB1bnNpZ25lZCBpbnQs IGludCk7CiAjaWYgX19CU0RfVklTSUJMRQogaW50CXNlbmRmaWxlKGludCwgaW50LCBvZmZfdCwg c2l6ZV90LCBzdHJ1Y3Qgc2ZfaGR0ciAqLCBvZmZfdCAqLCBpbnQpOwogaW50CXNldGZpYihpbnQp Owo= --089e01493c12bf93910528bbeec6-- From owner-freebsd-net@freebsd.org Thu Jan 7 10:34:47 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6B82A65785 for ; Thu, 7 Jan 2016 10:34:47 +0000 (UTC) (envelope-from h.skuhra@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 740EA110E for ; Thu, 7 Jan 2016 10:34:47 +0000 (UTC) (envelope-from h.skuhra@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id b14so116049878wmb.1 for ; Thu, 07 Jan 2016 02:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:mime-version:content-type; bh=H239HDGCw0Ppz08KVOsUdWltdwYNSldC07sf8sx2MJM=; b=MEntQfO9INRCjwLqFTCvPbS/NsCZg4fm1mG98sErwYog+TO2/igEoMDxPMblevpwdP GKyoWLrIUuzZUDXmwPZ7FnvwtpozlBjXyJLLusq/c4FDHlySVBwcluRax1AygynGwgex a4GNVLrUNqtXX4fYaLTBs1XebBkuUW90x7Qdagi9c5f45syBmEE6NOGglQ7Y4VqzE1N1 vonsTHStO0RvQyq7AkCKEWp+ZCtoTopI9W7ubQvXCbj/2wOX9EVpjWuylfFXtV3gOCGG 9mJ78jDMPZ9W7UaK/cg3phIY+SAnVqfuCphylduW/1bw6t++ukF57hrcnrYhOW6lvXiR tB/Q== X-Received: by 10.28.133.141 with SMTP id h135mr15207345wmd.70.1452162885850; Thu, 07 Jan 2016 02:34:45 -0800 (PST) Received: from oslo.ath.cx ([2a02:b18:581:10:9402:4c98:7d6c:8518]) by smtp.gmail.com with ESMTPSA id pn6sm100412786wjb.15.2016.01.07.02.34.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2016 02:34:45 -0800 (PST) Date: Thu, 07 Jan 2016 11:34:43 +0100 Message-ID: <86twmpada4.wl-h.skuhra@gmail.com> From: "Herbert J. Skuhra" To: Ben Woods Cc: freebsd-net@freebsd.org Subject: Re: ppp(8) PPPoE fails when ifname contains "." In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.0.50 (i386-pc-freebsd10.2) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 10:34:47 -0000 On Wed, 06 Jan 2016 23:29:09 +0100, Ben Woods wrote: > > Hey everyone, > > I was recently trying to set up PPPoE to my ISP, over my network interface > which is configured with 802.1q VLAN tagging using vlan(4). > > I utilised the vlans_= feature described in rc.conf(5), > which creates a cloned interface named .. > > In /etc/ppp.conf I used the syntax PPPoE:. and this exposed > an interesting issue - ppp(8) would not set up the PPPoE interface > correctly when the interface contains a period. > > When I manually created the vlan clone interface with a name not containing > a period, ppp(8) worked fine. > > Has anyone seen this before? A quick review of the ppp(8) code, and I am > struggling to see the exact point where this syntax problem is. Like this: https://lists.freebsd.org/pipermail/freebsd-stable/2009-July/051096.html -- Herbert From owner-freebsd-net@freebsd.org Thu Jan 7 10:54:24 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8606FA65EC8 for ; Thu, 7 Jan 2016 10:54:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15CF71DA0 for ; Thu, 7 Jan 2016 10:54:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u07AsIoB087955 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 12:54:19 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u07AsIoB087955 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u07AsIO5087954; Thu, 7 Jan 2016 12:54:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 7 Jan 2016 12:54:18 +0200 From: Konstantin Belousov To: Boris Astardzhiev Cc: Mark Delany , freebsd-net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160107105418.GS3625@kib.kiev.ua> References: <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107101351.GR3625@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 10:54:24 -0000 On Thu, Jan 07, 2016 at 12:28:32PM +0200, Boris Astardzhiev wrote: See inline comments and final notes at the end. > diff --git a/lib/libc/include/libc_private.h b/lib/libc/include/libc_private.h > index 5caf9a3..7e2a902 100644 > --- a/lib/libc/include/libc_private.h > +++ b/lib/libc/include/libc_private.h > @@ -200,8 +200,10 @@ enum { > INTERPOS_pselect, > INTERPOS_recvfrom, > INTERPOS_recvmsg, > + INTERPOS_recvmmsg, > INTERPOS_select, > INTERPOS_sendmsg, > + INTERPOS_sendmmsg, > INTERPOS_sendto, > INTERPOS_setcontext, > INTERPOS_sigaction, The interposing table must be extended at the end, and not in the middle. otherwise you introduce too large inconsistence with older libthr. That said, you changed libc table, but did not updated libthr. The result is random segfaults in the multithreaded processes. > diff --git a/lib/libc/sys/Symbol.map b/lib/libc/sys/Symbol.map > index 7b3257c..6cc3c6e 100644 > --- a/lib/libc/sys/Symbol.map > +++ b/lib/libc/sys/Symbol.map > @@ -220,6 +220,7 @@ FBSD_1.0 { > reboot; > recvfrom; > recvmsg; > + recvmmsg; > rename; > revoke; > rfork; > @@ -240,6 +241,7 @@ FBSD_1.0 { > semsys; > sendfile; > sendmsg; > + sendmmsg; > sendto; > setaudit; > setaudit_addr; The versioning is wrong, new non-private symbols for 11.0 go into _1.4. > @@ -851,6 +853,8 @@ FBSDprivate_1.0 { > __sys_recvfrom; > _recvmsg; > __sys_recvmsg; > + _recvmmsg; > + __sys_recvmmsg; > _rename; > __sys_rename; > _revoke; > @@ -891,6 +895,8 @@ FBSDprivate_1.0 { > __sys_sendfile; > _sendmsg; > __sys_sendmsg; > + _sendmmsg; > + __sys_sendmmsg; > _sendto; > __sys_sendto; > _setaudit; > diff --git a/sys/kern/uipc_syscalls.c b/sys/kern/uipc_syscalls.c > index c33a2cf..7354b4f 100644 > --- a/sys/kern/uipc_syscalls.c > +++ b/sys/kern/uipc_syscalls.c > +int > +sys_recvmmsg(td, uap) > + struct thread *td; > + struct recvmmsg_args /* { > + int s; > + struct mmsghdr *msgvec; > + unsigned int vlen; > + int flags; > + } */ *uap; Use ANSI C definitions for new code, please. I personally do not inline uap declaration, the time has gone. > +{ > + struct mmsghdr *vec, *mmp; > + struct msghdr *mp, msg; > + struct iovec *uiov, *iov; > + unsigned int vlen, len; > + int i, rcvd = 0, error; > + struct socket *so = NULL; Style, no initialization in declaration. > + struct file *fp; > + cap_rights_t rights; > + > + if (fget(td, uap->s, cap_rights_init(&rights, CAP_RECV), &fp) != 0) > + return (EBADF); > + > + so = fp->f_data; What if uap->s filedescriptor does not reference a socket ? > + > + vlen = uap->vlen; > + if (vlen > UIO_MAXIOV) > + vlen = UIO_MAXIOV; > + > + len = vlen * sizeof(*uap->msgvec); > + vec = malloc(len, M_TEMP, M_WAITOK); This is a user-controlled malloc(9), i.e. an easy kernel panic due to impossible to satisfy request, or KVA and memory exhaustion. > + > + error = copyin(uap->msgvec, vec, len); > + if (error != 0) > + goto out; > + > + for (i = 0; i < vlen; i++) { > + mmp = &vec[i]; > + mp = &mmp->msg_hdr; > + msg = *mp; > + > + error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE); > + if (error != 0) > + goto out; > + > + msg.msg_flags = uap->flags; > +#ifdef COMPAT_OLDSOCK > + msg.msg_flags &= ~MSG_COMPAT; > +#endif > + uiov = msg.msg_iov; > + msg.msg_iov = iov; > + > + error = recvit(td, uap->s, &msg, NULL); > + if (error == 0) { > + msg.msg_iov = uiov; > + error = copyout(&msg, &uap->msgvec[i].msg_hdr, sizeof(msg)); > + if (error != 0) { > + free(iov, M_IOV); > + goto out; > + } > + error = copyout(&td->td_retval[0], &uap->msgvec[i].msg_len, > + sizeof(td->td_retval[0])); > + if (error != 0) { > + free(iov, M_IOV); > + goto out; > + } > + } > + free(iov, M_IOV); > + rcvd++; > + } > + > + td->td_retval[0] = rcvd; > + > +out: > + if (error != 0 && rcvd != 0 && rcvd != vlen) { > + so->so_error = error; > + error = 0; > + td->td_retval[0] = rcvd; > + } > + > + fdrop(fp, td); > + > + free(vec, M_TEMP); > + return (error); > +} > + > /* ARGSUSED */ > int > sys_shutdown(td, uap) > diff --git a/sys/sys/socket.h b/sys/sys/socket.h > index 18e2de1..d352cd2 100644 > --- a/sys/sys/socket.h > +++ b/sys/sys/socket.h > @@ -414,6 +414,11 @@ struct msghdr { > int msg_flags; /* flags on received message */ > }; > > +struct mmsghdr { > + struct msghdr msg_hdr; /* message header */ > + unsigned int msg_len; /* message length */ > +}; > + > #define MSG_OOB 0x1 /* process out-of-band data */ > #define MSG_PEEK 0x2 /* peek at incoming message */ > #define MSG_DONTROUTE 0x4 /* send without using routing tables */ > @@ -615,10 +620,12 @@ int listen(int, int); > ssize_t recv(int, void *, size_t, int); > ssize_t recvfrom(int, void *, size_t, int, struct sockaddr * __restrict, socklen_t * __restrict); > ssize_t recvmsg(int, struct msghdr *, int); > +ssize_t recvmmsg(int, struct mmsghdr *, unsigned int, int); > ssize_t send(int, const void *, size_t, int); > ssize_t sendto(int, const void *, > size_t, int, const struct sockaddr *, socklen_t); > ssize_t sendmsg(int, const struct msghdr *, int); > +ssize_t sendmmsg(int, const struct mmsghdr *, unsigned int, int); Why did you put new functions into POSIX namespace ? They are GNU (and now BSD) extensions, at least I do not see then in SUS. > #if __BSD_VISIBLE > int sendfile(int, int, off_t, size_t, struct sf_hdtr *, off_t *, int); > int setfib(int); The patch lacks man page update, and lacks the freebsd32 compat shims. What are the reasons to go with the trivial kernel implementation right now, instead of trivial and simpler libc wrapper ? I think the speed would be same, but the code _much_ simpler. From owner-freebsd-net@freebsd.org Thu Jan 7 10:56:56 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F134BA65F94 for ; Thu, 7 Jan 2016 10:56:56 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (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 7AF6D1E92 for ; Thu, 7 Jan 2016 10:56:56 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lb0-x22d.google.com with SMTP id pv2so221194692lbb.1 for ; Thu, 07 Jan 2016 02:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jjBs39r6n8jOrSeIHdwXD5zsZq7OIY7t66Sq64pbXiQ=; b=hGANXI8xlN9CQEeGKV8T9Vxq6tagiqmZZv1eBsVB6/5wizYHdOnqXoAi9JsvX8079D g4W/pYyLRaZtCsWxoea9Qsa7Xf4myDSgqCeWfPm8FGcLO5rmpBiiuZIPaNLl/on6j6Cs rGxhNnfWMqI7LuVnlDR2kP9VetlRIJzApKuxZ6R1qEebJfgIP3P6b9yj2qmY3+/vfCTl YQZVe3rnT/epvSB/y4Kp0DXWCL3ljh3Qn1W9qX0CvT4AYJfWBIwyqrnTo7dkKspb50PS FCS8KQEwZGQmFFozQs8vqYORIpCbdbLDf339qpXTrLNxQep7ncxNIBNPJO8AmzaqjERY Z1bA== MIME-Version: 1.0 X-Received: by 10.112.45.138 with SMTP id n10mr30578264lbm.100.1452164212996; Thu, 07 Jan 2016 02:56:52 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.13.33 with HTTP; Thu, 7 Jan 2016 02:56:52 -0800 (PST) In-Reply-To: References: <1451841004.10139.34.camel@me.com> <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> Date: Thu, 7 Jan 2016 02:56:52 -0800 X-Google-Sender-Auth: 3Z8c-OnbKjVAFt-yWgrrGRJ24z4 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Luigi Rizzo To: Boris Astardzhiev Cc: Mark Delany , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 10:56:57 -0000 Hi Boris, thanks for working on this. A few comments: - do you have any performance data on calling *mmsg() versus multiple invocations of the equivalent *msg() ? - in the following chunk in recvmmsg.c , there are slight type differences between the function and the internal cast. Same in sendmmsg.c +ssize_t +recvmmsg(int s, struct mmsghdr *msgvec, unsigned int vlen, int flags) +{ + + return (((int (*)(int, struct mmsghdr *, int, int)) + __libc_interposing[INTERPOS_recvmmsg])(s, msgvec, vlen, flags)); +} - why did you add a cap_rights_init() to the functions when neither sendmsg or recvmsg have it (in other words, this is a worthwhile addition but perhaps should be done later - the initial part of the two functions sys_*mmsg() is almost exactly the same so can you define a function with the common code ? - you could probably avoid the repeated malloc/free of the iov with a first loop that finds the max iov size and does the allocation only once. copyiniov can then be replaced by a copyin - (minor) what is the point of copying the current entry into msg rather than just using mp-> ... - can you add a comment explaining why you do the following error = copyout(&td->td_retval[0], &uap->msgvec[i].msg_len, sizeof(td->td_retval[0])); cheers luigi On Thu, Jan 7, 2016 at 1:51 AM, Boris Astardzhiev wrote: > Hello, > > Here's my implementation of the two system calls. The patch is against HEAD > from a couple of days: > commit ff9e83788d7ed52342dcba4dff1e62fdf3cc985c > Author: ngie > Date: Mon Jan 4 03:34:22 2016 +0000 > > Remove free'ing of an uninitialized variable > > Just remove it completely from the test as it's initialized but unused > apart > from the free(3) call > > Differential Revision: https://reviews.freebsd.org/D4769 (part of > larger diff) > MFC after: 5 days > Reported by: cppcheck > Reviewed by: oshogbo > Sponsored by: EMC / Isilon Storage Division > > I've made brief tests using the examples in the manpages in Linux skipping > the timeout stuff: > http://man7.org/linux/man-pages/man2/sendmmsg.2.html > http://man7.org/linux/man-pages/man2/recvmmsg.2.html > > I've tried to stick to the comments in the thread but any > suggestions/testings > are also welcomed so that I can fix the calls accordingly. > > Regards, > Boris Astardzhiev > > > On Mon, Jan 4, 2016 at 11:07 PM, Mark Delany wrote: > >> > You just repeat arguments for the text in my messages, which you removed >> > on reply. >> >> My goal is to get you to scruitinize. >> >> Thank you for helping. >> >> >> Mark. >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@freebsd.org Thu Jan 7 11:07:58 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13346A6636E for ; Thu, 7 Jan 2016 11:07:58 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 9610615B2 for ; Thu, 7 Jan 2016 11:07:57 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x235.google.com with SMTP id z124so324929073lfa.3 for ; Thu, 07 Jan 2016 03:07:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=KqAEe/VWYm5x8qkoWSTZuw41Di3pZlwSW9lotIL/YgA=; b=ZxVc8lOlgOFU+GO9ccGshhiW+7emvNoemz8co34BjdBPgcd+ehTUvU6xV1LMWXevCj Mg4lL80e6Vuufwjld/SvMQPxN/CvzMtHCfpONN0Zv/+8QgUVvbavbtUMLtxrN+ItSXMt l03irF//A+lups2qZvqQcZtRMPuu/0mKj9zZsRMI4QClpZC8BQTC1cDHdLJVQ9D/JV4z BnbWsUHTVZ6/+zjbkQo94eJzhDfubC0gpREL98W2qH9VLSpsEDNRChDlsZYjSelf9Hvi gnHXJ4cqEfYo9l6iHYyt+U1RtaEADaqKazXwPExwa81XAI6F7l9BBYvVKeoMVyQ6AZJL sDUA== MIME-Version: 1.0 X-Received: by 10.25.25.142 with SMTP id 136mr32035045lfz.42.1452164875697; Thu, 07 Jan 2016 03:07:55 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.13.33 with HTTP; Thu, 7 Jan 2016 03:07:55 -0800 (PST) Date: Thu, 7 Jan 2016 03:07:55 -0800 X-Google-Sender-Auth: sTSYjmAn2-aj8eSBwvUkJsL47AE Message-ID: Subject: generated files (Re: Does FreeBSD have sendmmsg or recvmmsg system calls?) From: Luigi Rizzo To: Konstantin Belousov Cc: Boris Astardzhiev , Mark Delany , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 11:07:58 -0000 I wonder how complex it would be to autogenerate at least part of the various components required when adding a syscall like this. It looks like the number of places to touch (see chunks below) and the ordering constraints make the manual process very prone to errors. This said, it might be nice to add some explanation in the various places, e.g. Symbol.map could do with a comment describing the meaning of the various groups FBSD_1.0 FBSD_1.1 FBSDprivate_1.0 and so on. cheers luigi On Thu, Jan 7, 2016 at 2:54 AM, Konstantin Belousov wrote: > On Thu, Jan 07, 2016 at 12:28:32PM +0200, Boris Astardzhiev wrote: > See inline comments and final notes at the end. > >> diff --git a/lib/libc/include/libc_private.h b/lib/libc/include/libc_private.h >> index 5caf9a3..7e2a902 100644 >> --- a/lib/libc/include/libc_private.h >> +++ b/lib/libc/include/libc_private.h >> @@ -200,8 +200,10 @@ enum { >> INTERPOS_pselect, >> INTERPOS_recvfrom, >> INTERPOS_recvmsg, >> + INTERPOS_recvmmsg, >> INTERPOS_select, >> INTERPOS_sendmsg, >> + INTERPOS_sendmmsg, >> INTERPOS_sendto, >> INTERPOS_setcontext, >> INTERPOS_sigaction, > The interposing table must be extended at the end, and not in the middle. > otherwise you introduce too large inconsistence with older libthr. > > That said, you changed libc table, but did not updated libthr. The result > is random segfaults in the multithreaded processes. > >> diff --git a/lib/libc/sys/Symbol.map b/lib/libc/sys/Symbol.map >> index 7b3257c..6cc3c6e 100644 >> --- a/lib/libc/sys/Symbol.map >> +++ b/lib/libc/sys/Symbol.map >> @@ -220,6 +220,7 @@ FBSD_1.0 { >> reboot; >> recvfrom; >> recvmsg; >> + recvmmsg; >> rename; >> revoke; >> rfork; >> @@ -240,6 +241,7 @@ FBSD_1.0 { >> semsys; >> sendfile; >> sendmsg; >> + sendmmsg; >> sendto; >> setaudit; >> setaudit_addr; > The versioning is wrong, new non-private symbols for 11.0 go into _1.4. > From owner-freebsd-net@freebsd.org Thu Jan 7 11:36:15 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4872EA66ECF for ; Thu, 7 Jan 2016 11:36:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC6B61082 for ; Thu, 7 Jan 2016 11:36:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u07Ba98n098685 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 13:36:09 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u07Ba98n098685 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u07Ba74N098678; Thu, 7 Jan 2016 13:36:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 7 Jan 2016 13:36:07 +0200 From: Konstantin Belousov To: Luigi Rizzo Cc: Boris Astardzhiev , Mark Delany , "freebsd-net@freebsd.org" Subject: Re: generated files (Re: Does FreeBSD have sendmmsg or recvmmsg system calls?) Message-ID: <20160107113607.GT3625@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 11:36:15 -0000 On Thu, Jan 07, 2016 at 03:07:55AM -0800, Luigi Rizzo wrote: > I wonder how complex it would be to autogenerate > at least part of the various components required > when adding a syscall like this. There are two places in libc that need updating when adding a new syscall. One is the sys/Symbol.map. You add the syscall name in the right block, and since the correspondence between syscall and version is needed for autogeneration, the autogeneration would not save you any work. Another part, which was done wrong in the patch, is the handling of the cancellable syscalls. For each cancellation point, the behaviour is very specific. This, and the fact that there are approximately two dozens of cancellable syscalls among ~500 total, make any sort of automation more complex than no automation at all. And note that in the current proposal, just doing loop in libc would manage this stuff correctly. If protocols become smarter and provide the mm- variants, then the syscalls would make more sense, and the perceived complexity of the libc changes would be invisible. > > It looks like the number of places to touch (see chunks > below) and the ordering constraints make the manual process very prone > to errors. Well, you need to understand what you do. The placess to fill are not formal or arbitrary, there are choices that affect behaviour and correctness. > > This said, it might be nice to add some explanation > in the various places, e.g. Symbol.map could do > with a comment describing the meaning of the various > groups FBSD_1.0 FBSD_1.1 FBSDprivate_1.0 and so on. Definitely. Look at libc/Versions.def. There is no explanation for cancellation stuff, but most of it follows from the specification. From owner-freebsd-net@freebsd.org Thu Jan 7 13:31:27 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 604F8A6672D for ; Thu, 7 Jan 2016 13:31:27 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 DF8401F25 for ; Thu, 7 Jan 2016 13:31:26 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id b14so123411240wmb.1 for ; Thu, 07 Jan 2016 05:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4cnwFQ5795a+J3iQGIvSwjFXuJ4KmxU2GrmC1GTP7T0=; b=CA6Ap29giQ6fonFckxI1BVgCxCBsscgk64mFy1JOGaQJT0Tw11sOW3g7ftKpxblri9 M1qNB1aIYo1D+POZbT7qemzeQTGlmH1YUfP1icKVdyIfACBGGyemUzyRhbekwg79j9tC SgX7QQ0cBUMKbXKgXD3BhLH9Y2A/nJ5nAtdVQi/gRN4pegXZrsfsKmfV/IWoP0+OTK+W Se6YRf2uEw1a9uPf3bgyoDDR/XFf1Mu6mj8b6g5U0TCVgbVSnQxdW0JMU/IAas7uao1U vKf1fXfdiXSJ1+F1G/+pDygsbLkDV7oCA3pFiD+yIadxYAFtHY817k18CMGqqNMt0j+5 quhA== MIME-Version: 1.0 X-Received: by 10.194.78.175 with SMTP id c15mr72432721wjx.16.1452173485385; Thu, 07 Jan 2016 05:31:25 -0800 (PST) Received: by 10.28.136.148 with HTTP; Thu, 7 Jan 2016 05:31:25 -0800 (PST) In-Reply-To: References: <1451841004.10139.34.camel@me.com> <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> Date: Thu, 7 Jan 2016 15:31:25 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: Luigi Rizzo Cc: Mark Delany , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:31:27 -0000 >Hi Boris, >thanks for working on this. > >A few comments: > >- do you have any performance data on calling *mmsg() versus > multiple invocations of the equivalent *msg() ? No, I don't for now. >- in the following chunk in recvmmsg.c , there are slight > type differences between the function and the internal cast. > Same in sendmmsg.c > > +ssize_t > +recvmmsg(int s, struct mmsghdr *msgvec, unsigned int vlen, int flags) > +{ > + > + return (((int (*)(int, struct mmsghdr *, int, int)) > + __libc_interposing[INTERPOS_recvmmsg])(s, msgvec, vlen, flags)); > +} I see. I'll fix it. >- why did you add a cap_rights_init() to the functions when > neither sendmsg or recvmsg have it (in other words, this is > a worthwhile addition but perhaps should be done later I need to grab access to so_error due to error handling. send/recvmmsg() would have to return the number of datagrams sent/rcvd. send/recvmsg() return the number of characters sent/rcvd. Thus I followed Konstantin's explanation regarding so_error. >- the initial part of the two functions sys_*mmsg() is almost > exactly the same so can you define a function with the common code ? >- you could probably avoid the repeated malloc/free of the iov > with a first loop that finds the max iov size and does the allocation > only once. copyiniov can then be replaced by a copyin I'll try to optimize the calls at the end. I like the suggestion though and I'll scrutinize over it. >- (minor) what is the point of copying the current entry into msg rather than > just using mp-> ... Just my style for making things more readable to me. >- can you add a comment explaining why you do the following > > error = copyout(&td->td_retval[0], &uap->msgvec[i].msg_len, > sizeof(td->td_retval[0])); Thank you. I'll add a comment for clarification. Best Regards, Boris Astardzhiev On Thu, Jan 7, 2016 at 12:56 PM, Luigi Rizzo wrote: > Hi Boris, > thanks for working on this. > > A few comments: > > - do you have any performance data on calling *mmsg() versus > multiple invocations of the equivalent *msg() ? > > - in the following chunk in recvmmsg.c , there are slight > type differences between the function and the internal cast. > Same in sendmmsg.c > > +ssize_t > +recvmmsg(int s, struct mmsghdr *msgvec, unsigned int vlen, int flags) > +{ > + > + return (((int (*)(int, struct mmsghdr *, int, int)) > + __libc_interposing[INTERPOS_recvmmsg])(s, msgvec, vlen, > flags)); > +} > > > - why did you add a cap_rights_init() to the functions when > neither sendmsg or recvmsg have it (in other words, this is > a worthwhile addition but perhaps should be done later > > - the initial part of the two functions sys_*mmsg() is almost > exactly the same so can you define a function with the common code ? > > - you could probably avoid the repeated malloc/free of the iov > with a first loop that finds the max iov size and does the allocation > only once. copyiniov can then be replaced by a copyin > > - (minor) what is the point of copying the current entry into msg rather > than > just using mp-> ... > > - can you add a comment explaining why you do the following > > error = copyout(&td->td_retval[0], &uap->msgvec[i].msg_len, > sizeof(td->td_retval[0])); > > > cheers > luigi > > On Thu, Jan 7, 2016 at 1:51 AM, Boris Astardzhiev > wrote: > > Hello, > > > > Here's my implementation of the two system calls. The patch is against > HEAD > > from a couple of days: > > commit ff9e83788d7ed52342dcba4dff1e62fdf3cc985c > > Author: ngie > > Date: Mon Jan 4 03:34:22 2016 +0000 > > > > Remove free'ing of an uninitialized variable > > > > Just remove it completely from the test as it's initialized but > unused > > apart > > from the free(3) call > > > > Differential Revision: https://reviews.freebsd.org/D4769 (part of > > larger diff) > > MFC after: 5 days > > Reported by: cppcheck > > Reviewed by: oshogbo > > Sponsored by: EMC / Isilon Storage Division > > > > I've made brief tests using the examples in the manpages in Linux > skipping > > the timeout stuff: > > http://man7.org/linux/man-pages/man2/sendmmsg.2.html > > http://man7.org/linux/man-pages/man2/recvmmsg.2.html > > > > I've tried to stick to the comments in the thread but any > > suggestions/testings > > are also welcomed so that I can fix the calls accordingly. > > > > Regards, > > Boris Astardzhiev > > > > > > On Mon, Jan 4, 2016 at 11:07 PM, Mark Delany wrote: > > > >> > You just repeat arguments for the text in my messages, which you > removed > >> > on reply. > >> > >> My goal is to get you to scruitinize. > >> > >> Thank you for helping. > >> > >> > >> Mark. > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >> > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2217533 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > From owner-freebsd-net@freebsd.org Thu Jan 7 13:37:13 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EE54A669BD for ; Thu, 7 Jan 2016 13:37:13 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 A0E5812A0 for ; Thu, 7 Jan 2016 13:37:12 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id f206so97542605wmf.0 for ; Thu, 07 Jan 2016 05:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=la1Ix/xBkN6QSjmXINUdtGM0vHMvDykcMnBrRkkRRZA=; b=UOfWHB/A106I8M55BQ995f5aX/eZrWMjgZAAcpIvQj8JvK2y49Uozq6Px+zwVjpBbO Xlwv0hnmxJriPi45VrELvUNXIy0pmA4JCu8gVE8MxxHSyk2XrMkNu7UKipzQoNGULx08 WfYBL2Yq9kZkPrvKeHEl4vOPiUKCJM1M1BmgQomlNbUf39bL2p5xqIlXePPxkYv5wgPG MisYcl/9ywtV6is0ov4ohRrPGbfrAAl4u8NAqKpi0CCNLv+y1inmGw4F2GYMrULbtkGm dZfdPvjTIaT98k/kcj+nxgDtIEcb2xXHX3rm9kgGWaUfmI26fB49UFhLPUv72HqrqJXB kB0w== MIME-Version: 1.0 X-Received: by 10.28.186.85 with SMTP id k82mr17780854wmf.77.1452173363205; Thu, 07 Jan 2016 05:29:23 -0800 (PST) Received: by 10.28.136.148 with HTTP; Thu, 7 Jan 2016 05:29:23 -0800 (PST) In-Reply-To: References: <1451841004.10139.34.camel@me.com> <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> Date: Thu, 7 Jan 2016 15:29:23 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: Luigi Rizzo Cc: Mark Delany , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:37:13 -0000 First of all thanks for the insightful code review. >>On Thu, Jan 07, 2016 at 12:28:32PM +0200, Boris Astardzhiev wrote: >>See inline comments and final notes at the end. >> >> diff --git a/lib/libc/include/libc_private.h b/lib/libc/include/libc_private.h >> index 5caf9a3..7e2a902 100644 >> --- a/lib/libc/include/libc_private.h >> +++ b/lib/libc/include/libc_private.h >> @@ -200,8 +200,10 @@ enum { >> INTERPOS_pselect, >> INTERPOS_recvfrom, >> INTERPOS_recvmsg, >> + INTERPOS_recvmmsg, >> INTERPOS_select, >> INTERPOS_sendmsg, >> + INTERPOS_sendmmsg, >> INTERPOS_sendto, >> INTERPOS_setcontext, >> INTERPOS_sigaction, >The interposing table must be extended at the end, and not in the middle. >otherwise you introduce too large inconsistence with older libthr. > >That said, you changed libc table, but did not updated libthr. The result >is random segfaults in the multithreaded processes. Thanks for this catch. I'll fix it. >> diff --git a/lib/libc/sys/Symbol.map b/lib/libc/sys/Symbol.map >> index 7b3257c..6cc3c6e 100644 >> --- a/lib/libc/sys/Symbol.map >> +++ b/lib/libc/sys/Symbol.map >> @@ -220,6 +220,7 @@ FBSD_1.0 { >> reboot; >> recvfrom; >> recvmsg; >> + recvmmsg; >> rename; >> revoke; >> rfork; >> @@ -240,6 +241,7 @@ FBSD_1.0 { >> semsys; >> sendfile; >> sendmsg; >> + sendmmsg; >> sendto; >> setaudit; >> setaudit_addr; >The versioning is wrong, new non-private symbols for 11.0 go into _1.4. > >> @@ -851,6 +853,8 @@ FBSDprivate_1.0 { >> __sys_recvfrom; >> _recvmsg; >> __sys_recvmsg; >> + _recvmmsg; >> + __sys_recvmmsg; >> _rename; >> __sys_rename; >> _revoke; >> @@ -891,6 +895,8 @@ FBSDprivate_1.0 { >> __sys_sendfile; >> _sendmsg; >> __sys_sendmsg; >> + _sendmmsg; >> + __sys_sendmmsg; >> _sendto; >> __sys_sendto; >> _setaudit; I see. I'll put everything in FBSD_1.4. >> diff --git a/sys/kern/uipc_syscalls.c b/sys/kern/uipc_syscalls.c >> index c33a2cf..7354b4f 100644 >> --- a/sys/kern/uipc_syscalls.c >> +++ b/sys/kern/uipc_syscalls.c > >> +int >> +sys_recvmmsg(td, uap) >> + struct thread *td; >> + struct recvmmsg_args /* { >> + int s; >> + struct mmsghdr *msgvec; >> + unsigned int vlen; >> + int flags; >> + } */ *uap; >Use ANSI C definitions for new code, please. >I personally do not inline uap declaration, the time has gone. I'll fix it. >> +{ >> + struct mmsghdr *vec, *mmp; >> + struct msghdr *mp, msg; >> + struct iovec *uiov, *iov; >> + unsigned int vlen, len; >> + int i, rcvd = 0, error; >> + struct socket *so = NULL; >Style, no initialization in declaration. I'll fix it. >> + struct file *fp; >> + cap_rights_t rights; >> + >> + if (fget(td, uap->s, cap_rights_init(&rights, CAP_RECV), &fp) != 0) >> + return (EBADF); >> + >> + so = fp->f_data; >What if uap->s filedescriptor does not reference a socket ? kern_sendit/recvit() eventually call getsock_cap(). To me this means that send/recv(m)msg have to be limited only to sockets. I was in a need to grab access to so_error due to the error handling later. Probably I need to use something similar like kern_sendit/recvit's getsock_cap approach. Comments or a better approach to so_error? >>> + >>> + vlen = uap->vlen; >>> + if (vlen > UIO_MAXIOV) >>> + vlen = UIO_MAXIOV; >>> + >>> + len = vlen * sizeof(*uap->msgvec); >>> + vec = malloc(len, M_TEMP, M_WAITOK); >>This is a user-controlled malloc(9), i.e. an easy kernel panic due to >>impossible to satisfy request, or KVA and memory exhaustion. Having a glance in the manpage there it is stated that: M_WAITOK Indicates that it is OK to wait for resources. If the request cannot be immediately fulfilled, the current process is put to sleep to wait for resources to be released by other processes. The malloc(), realloc(), and reallocf() functions cannot return NULL if M_WAITOK is specified. I.e we'll be put to sleep and no NULL will be returned. I don't see how I'll get a panic here. Or you're stressing the malloc type M_TEMP here? More clarifications? >> + >> + error = copyin(uap->msgvec, vec, len); >> + if (error != 0) >> + goto out; >> + >> + for (i = 0; i < vlen; i++) { >> + mmp = &vec[i]; >> + mp = &mmp->msg_hdr; >> + msg = *mp; >> + >> + error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE); >> + if (error != 0) >> + goto out; >> + >> + msg.msg_flags = uap->flags; >> +#ifdef COMPAT_OLDSOCK >> + msg.msg_flags &= ~MSG_COMPAT; >> +#endif >> + uiov = msg.msg_iov; >> + msg.msg_iov = iov; >> + >> + error = recvit(td, uap->s, &msg, NULL); >> + if (error == 0) { >> + msg.msg_iov = uiov; >> + error = copyout(&msg, &uap->msgvec[i].msg_hdr, sizeof(msg)); >> + if (error != 0) { >> + free(iov, M_IOV); >> + goto out; >> + } >> + error = copyout(&td->td_retval[0], &uap->msgvec[i].msg_len, >> + sizeof(td->td_retval[0])); >> + if (error != 0) { >> + free(iov, M_IOV); >> + goto out; >> + } >> + } >> + free(iov, M_IOV); >> + rcvd++; >> + } >> + >> + td->td_retval[0] = rcvd; >> + >> +out: >> + if (error != 0 && rcvd != 0 && rcvd != vlen) { >> + so->so_error = error; >> + error = 0; >> + td->td_retval[0] = rcvd; >> + } >> + >> + fdrop(fp, td); >> + >> + free(vec, M_TEMP); >> + return (error); >> +} >> + >> /* ARGSUSED */ >> int >> sys_shutdown(td, uap) >> diff --git a/sys/sys/socket.h b/sys/sys/socket.h >> index 18e2de1..d352cd2 100644 >> --- a/sys/sys/socket.h >> +++ b/sys/sys/socket.h >> @@ -414,6 +414,11 @@ struct msghdr { >> int msg_flags; /* flags on received message */ >> }; >> >> +struct mmsghdr { >> + struct msghdr msg_hdr; /* message header */ >> + unsigned int msg_len; /* message length */ >> +}; >> + >> #define MSG_OOB 0x1 /* process out-of-band data */ >> #define MSG_PEEK 0x2 /* peek at incoming message */ >> #define MSG_DONTROUTE 0x4 /* send without using routing tables */ >> @@ -615,10 +620,12 @@ int listen(int, int); >> ssize_t recv(int, void *, size_t, int); >> ssize_t recvfrom(int, void *, size_t, int, struct sockaddr * __restrict, socklen_t * __restrict); >> ssize_t recvmsg(int, struct msghdr *, int); >> +ssize_t recvmmsg(int, struct mmsghdr *, unsigned int, int); >> ssize_t send(int, const void *, size_t, int); >> ssize_t sendto(int, const void *, >> size_t, int, const struct sockaddr *, socklen_t); >> ssize_t sendmsg(int, const struct msghdr *, int); >> +ssize_t sendmmsg(int, const struct mmsghdr *, unsigned int, int); >Why did you put new functions into POSIX namespace ? >They are GNU (and now BSD) extensions, at least I do not see then in SUS. > >> #if __BSD_VISIBLE >> int sendfile(int, int, off_t, size_t, struct sf_hdtr *, off_t *, int); >> int setfib(int); I agree. Guess I'll have to put it ifdef'd under __BSD_VISIBLE since it's not POSIX. >The patch lacks man page update, and lacks the freebsd32 compat shims. I'll work on these later. >What are the reasons to go with the trivial kernel implementation >right now, instead of trivial and simpler libc wrapper ? I think the >speed would be same, but the code _much_ simpler. My initial idea was such that with the kernel approach we get closer to the driver itself and if it has mm optimizations we may have a benefit in future. And thus one day we won't need to redo the work scrubbing the libc-only implementation. Best regards, Boris Astardzhiev On Thu, Jan 7, 2016 at 12:56 PM, Luigi Rizzo wrote: > Hi Boris, > thanks for working on this. > > A few comments: > > - do you have any performance data on calling *mmsg() versus > multiple invocations of the equivalent *msg() ? > > - in the following chunk in recvmmsg.c , there are slight > type differences between the function and the internal cast. > Same in sendmmsg.c > > +ssize_t > +recvmmsg(int s, struct mmsghdr *msgvec, unsigned int vlen, int flags) > +{ > + > + return (((int (*)(int, struct mmsghdr *, int, int)) > + __libc_interposing[INTERPOS_recvmmsg])(s, msgvec, vlen, > flags)); > +} > > > - why did you add a cap_rights_init() to the functions when > neither sendmsg or recvmsg have it (in other words, this is > a worthwhile addition but perhaps should be done later > > - the initial part of the two functions sys_*mmsg() is almost > exactly the same so can you define a function with the common code ? > > - you could probably avoid the repeated malloc/free of the iov > with a first loop that finds the max iov size and does the allocation > only once. copyiniov can then be replaced by a copyin > > - (minor) what is the point of copying the current entry into msg rather > than > just using mp-> ... > > - can you add a comment explaining why you do the following > > error = copyout(&td->td_retval[0], &uap->msgvec[i].msg_len, > sizeof(td->td_retval[0])); > > > cheers > luigi > > On Thu, Jan 7, 2016 at 1:51 AM, Boris Astardzhiev > wrote: > > Hello, > > > > Here's my implementation of the two system calls. The patch is against > HEAD > > from a couple of days: > > commit ff9e83788d7ed52342dcba4dff1e62fdf3cc985c > > Author: ngie > > Date: Mon Jan 4 03:34:22 2016 +0000 > > > > Remove free'ing of an uninitialized variable > > > > Just remove it completely from the test as it's initialized but > unused > > apart > > from the free(3) call > > > > Differential Revision: https://reviews.freebsd.org/D4769 (part of > > larger diff) > > MFC after: 5 days > > Reported by: cppcheck > > Reviewed by: oshogbo > > Sponsored by: EMC / Isilon Storage Division > > > > I've made brief tests using the examples in the manpages in Linux > skipping > > the timeout stuff: > > http://man7.org/linux/man-pages/man2/sendmmsg.2.html > > http://man7.org/linux/man-pages/man2/recvmmsg.2.html > > > > I've tried to stick to the comments in the thread but any > > suggestions/testings > > are also welcomed so that I can fix the calls accordingly. > > > > Regards, > > Boris Astardzhiev > > > > > > On Mon, Jan 4, 2016 at 11:07 PM, Mark Delany wrote: > > > >> > You just repeat arguments for the text in my messages, which you > removed > >> > on reply. > >> > >> My goal is to get you to scruitinize. > >> > >> Thank you for helping. > >> > >> > >> Mark. > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >> > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2217533 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > From owner-freebsd-net@freebsd.org Thu Jan 7 16:12:20 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B54E0A67747 for ; Thu, 7 Jan 2016 16:12:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 44CA61360 for ; Thu, 7 Jan 2016 16:12:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u07GCF82070949 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 18:12:15 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u07GCF82070949 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u07GCDRC070948; Thu, 7 Jan 2016 18:12:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 7 Jan 2016 18:12:13 +0200 From: Konstantin Belousov To: Boris Astardzhiev Cc: Luigi Rizzo , Mark Delany , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160107161213.GZ3625@kib.kiev.ua> References: <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:12:20 -0000 On Thu, Jan 07, 2016 at 03:29:23PM +0200, Boris Astardzhiev wrote: > First of all thanks for the insightful code review. > > >> + struct file *fp; > >> + cap_rights_t rights; > >> + > >> + if (fget(td, uap->s, cap_rights_init(&rights, CAP_RECV), &fp) != 0) > >> + return (EBADF); > >> + > >> + so = fp->f_data; > >What if uap->s filedescriptor does not reference a socket ? > > kern_sendit/recvit() eventually call getsock_cap(). > To me this means that send/recv(m)msg have to be limited only to sockets. > I was in a need to grab access to so_error due to the error handling later. > Probably I need to use something similar like kern_sendit/recvit's > getsock_cap approach. I missed this check, so my comment is not applicable. Hm, why do you need to fget() the uap->s filedescriptor at all ? Rather, I see why would you need it, but what is done is not completely correct. Note that userspace may close uap->s between two calls to kern_sendit(), or close and reopen for different kind of file, so your check at the start of the function is mostly useless. You should change the kern_sendit() interface to accept socket for this race to be eliminated, or move the guts of kern_sendit() into new function which takes socket as an argument. Then getsock_cap() would be done by your new syscall code and by kern_sendit() etc. After looking closer at it, additional argument to not use kern_sendit() is because you miss conditions like nullification of EINTR/ERESTART, which should stop the iteration. > Comments or a better approach to so_error? > > >>> + > >>> + vlen = uap->vlen; > >>> + if (vlen > UIO_MAXIOV) > >>> + vlen = UIO_MAXIOV; > >>> + > >>> + len = vlen * sizeof(*uap->msgvec); > >>> + vec = malloc(len, M_TEMP, M_WAITOK); > >>This is a user-controlled malloc(9), i.e. an easy kernel panic due to > >>impossible to satisfy request, or KVA and memory exhaustion. > > Having a glance in the manpage there it is stated that: > M_WAITOK > Indicates that it is OK to wait for resources. If the request > cannot be immediately fulfilled, the current process is put to > sleep to wait for resources to be released by other processes. > The malloc(), realloc(), and reallocf() functions cannot return > NULL if M_WAITOK is specified. > I.e we'll be put to sleep and no NULL will be returned. I don't see how I'll > get a panic here. Or you're stressing the malloc type M_TEMP here? > More clarifications? Suppose that malicious user code passed a value of 10 000 000 for uap->vlen. How many bytes for kernel malloc would be consumed ? This is local DoS. What would happen if the requested size is bigger than the kmem size, so that the allocation cannot succeed even theoretically ? > >What are the reasons to go with the trivial kernel implementation > >right now, instead of trivial and simpler libc wrapper ? I think the > >speed would be same, but the code _much_ simpler. > > My initial idea was such that with the kernel approach we get closer to the > driver itself and if it has mm optimizations we may have a benefit in > future. > And thus one day we won't need to redo the work scrubbing the libc-only > implementation. I suspect that the actual syscall interface would be more rich than the direct translation of the function signature into the syscall. IMO it would be easier for you to get the pure libc implementation correct for the first step. With such changes, I alway much prefer to have the hard part prototyped before making the bound changes in the API/ABI, which in this case means that some protocol should be enchanced to the multi-message interface. From owner-freebsd-net@freebsd.org Thu Jan 7 17:03:32 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA56CA66BBD for ; Thu, 7 Jan 2016 17:03:32 +0000 (UTC) (envelope-from vivek@mailermailer.com) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (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 7D04E18DA for ; Thu, 7 Jan 2016 17:03:32 +0000 (UTC) (envelope-from vivek@mailermailer.com) Received: by mail-qg0-x22b.google.com with SMTP id o11so332166144qge.2 for ; Thu, 07 Jan 2016 09:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailermailer.com; s=google; h=from:content-type:subject:message-id:date:to:mime-version; bh=pIoSHVlEyT1afRFlxtRlRNSfvl6JCB/Pc9Nnhxq4le0=; b=Nd7w3A6XePVzEEToZI5sWn8NsSVF+tDVrXhjXfUWmXR5288R7FuXMcYl8O/u3gV9w3 gO/LQnzSX12uKkIcfxX4ZWN53suD78mKjp2L5u7YY1tdnyDBODN7nglfHLgv45QX/xoP cDIUcMnBYbJaGXbiUad78ROhjIIW0H72RXQtI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=pIoSHVlEyT1afRFlxtRlRNSfvl6JCB/Pc9Nnhxq4le0=; b=B3lUQF5l6vKuwiyQ6CrqjQeMbGH+cdHG6DtFiIKFcM3a2pfeNxsuEruValIGKyViBS xJ4xxTTiWDZChCZqQCEJzA6GlZZwb0a1IoR20fh8LkzsEVvLP+h/egejYPia9dutXGtm DlOMT2bHffAHSIRZ/tbHAgl0kJ/+BqMftK/C/RNwbG+s3jtuTYKucgS+W+ayaY3G9W4J O1L4Bpvg9+HVuzFNbVDSnLM7lmuakxYhtxDo1Q891aBO66GQA9E1jggMK5c1ZmyfPXYe YpjWD5ZvkNgQ6fv1116oN+Hr07U8iY1GhvpLEb0VgSMtckoEwDXmgLrx4j4wk77w16kX drDg== X-Gm-Message-State: ALoCoQmpELzP8GoPiIy3gK4JtxobyzmoNQ0zuF3FIQrxoyQxiKh+HC94gOwPsU8rDE4Nk3aNoukQ9CALz0Zgmgtaomg1Qx2Qgw== X-Received: by 10.140.134.198 with SMTP id 189mr148916487qhg.58.1452186211434; Thu, 07 Jan 2016 09:03:31 -0800 (PST) Received: from vick.int.kcilink.com (74-92-149-60.static.comcast.kcilink.com. [74.92.149.60]) by smtp.gmail.com with ESMTPSA id b135sm3536491qka.2.2016.01.07.09.03.30 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Jan 2016 09:03:30 -0800 (PST) From: Vick Khera Content-Type: multipart/mixed; boundary="Apple-Mail=_28465A14-1206-49C8-A6B8-CE07E76BCD1C" Subject: 250x slowdown on localhost sockets with certain sized write(2) call from perl Message-Id: <2392D9E1-CA83-42F2-A3C9-DFF63772539F@mailermailer.com> Date: Thu, 7 Jan 2016 12:03:29 -0500 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:03:32 -0000 --Apple-Mail=_28465A14-1206-49C8-A6B8-CE07E76BCD1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I noticed a very curious slowdown in submitting email via a perl program = to a mail server running on the same host. I narrowed it down to = messages which were exactly 16332 bytes or shorted. Once they hit 16333 = bytes, they submit extremely fast. This slowdown only affects = connections on the local host. Connections to a remote mail server are = unaffected. I=E2=80=99m not 100% sure if this is a bug in FreeBSD or in Perl=E2=80=99s= Net::SMTP module, but the smallest test case I could come up with is = below. My hunch is that it is FreeBSD=E2=80=99s bug because I cannot = reproduce this problem on several linux versions. How to reproduce it: In window A, run "smtp-sink -c -4 :8025 10" with the smtp-sink program = from Postfix. Alternatively, run the "perl-sink" program below, which = requires the p5-Net-SMTP-Server package. You really don=E2=80=99t want = to point the test program at a real mail server, though it does the same = slowdown with postfix when sending a hand-crafted message of the right = size. In window B, run "perl standalone-smtp-speed.pl". On my FreeBSD 9.3 and = 10.2 systems, this output looks consistently like this: length=3D16327 elapsed =3D 0.106297 **SLOW length=3D16328 elapsed =3D 0.108077 **SLOW length=3D16329 elapsed =3D 0.101655 **SLOW length=3D16330 elapsed =3D 0.106082 **SLOW length=3D16331 elapsed =3D 0.10716 **SLOW length=3D16332 elapsed =3D 0.106499 **SLOW length=3D16333 elapsed =3D 0.00041 length=3D16334 elapsed =3D 0.00041 length=3D16335 elapsed =3D 0.000415 length=3D16336 elapsed =3D 0.000367 That is, up until the time the length of the message hits 16333 bytes, = it is about 250 times slower to send the message to the mail server. It = does not matter how many before or after messages are sent or what their = lengths are, it is always that length threshold that causes a material = shift in the time it takes. Perl=E2=80=99s SMTP send ultimately ends up calling syswrite() from = perl, which is write(2) from C. This is where the slowness comes, it = seems. The syswrite() always completes with one call =E2=80=94 no = retries are necessary for short writes. If you update the standalone-smtp-speed.pl script to point to the sink = program on a different host, all the lengths run fast. I tried to make a test case that just uses syswrite() directly without = the SMTP module, but I couldn=E2=80=99t do it. Maybe it requires some = data to be received too. I don=E2=80=99t know. Any ideas as to why? The only clue I found was this kernel PR = referencing the number 16332 as the length of partial writes to a = socket. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D173309 --Apple-Mail=_28465A14-1206-49C8-A6B8-CE07E76BCD1C Content-Disposition: attachment; filename=perl-sink Content-Type: application/octet-stream; name="perl-sink" Content-Transfer-Encoding: 7bit #!/usr/local/bin/perl use strict; use Net::SMTP::Server; use Net::SMTP::Server::Client; $|=1; my $s = new Net::SMTP::Server('vk-dev',8025); while (my $conn = $s->accept()) { my $client = new Net::SMTP::Server::Client($conn) || die("Unable to handle client connection: $!\n"); $client->process(); print "."; } --Apple-Mail=_28465A14-1206-49C8-A6B8-CE07E76BCD1C-- From owner-freebsd-net@freebsd.org Thu Jan 7 17:17:31 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32497A65150 for ; Thu, 7 Jan 2016 17:17:31 +0000 (UTC) (envelope-from mybsdmailing@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (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 0276A10C3 for ; Thu, 7 Jan 2016 17:17:31 +0000 (UTC) (envelope-from mybsdmailing@gmail.com) Received: by mail-ob0-x22f.google.com with SMTP id xn1so58086511obc.2 for ; Thu, 07 Jan 2016 09:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SRw8f4CfBye7OmIaBKuHphtTYeCOwDjJEvMTta3BiG0=; b=sTbYBRvgtqLHYIk2enTaP4ZAcQYudrl/WRoduM2pYELEIK+LJ+RMQkxsOWKCuZmikH y5mxNXdPS5Es5tNbRdg0RzmTcyq4qMpUObQMXKQc1e+cp4u6J/ngu1dagVdGsYIS3uSw Fu9p3abSP2dHgDjCL5gxdmOuOget5ri7g4rZtIfJCCHZ3CsPV+n5JeIjspxYBR/h+Ngw bgmdc+mNkBBkjHTEF1sQKa/NsspWtMLa0chBLEdCcfR3KVPEEi4qnFL3CjByz6/ouN7C ujikgFiYuggTeaEmoW/DSDPtsmjjKOCHPiE/Vp82TBH5EErWwepFSyvyjGswkqiprLaL qoew== MIME-Version: 1.0 X-Received: by 10.182.103.167 with SMTP id fx7mr75457353obb.36.1452187050399; Thu, 07 Jan 2016 09:17:30 -0800 (PST) Received: by 10.202.177.69 with HTTP; Thu, 7 Jan 2016 09:17:30 -0800 (PST) Date: Thu, 7 Jan 2016 11:17:30 -0600 Message-ID: Subject: tcpdump filter length Question From: Juan Herrera To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:17:31 -0000 Hello all, I am trying to do a tcpdump filter like below The idea is to filter all ethernet frames and where the frame ends as I understand keyword *len *has the total length of the captured packet, substracts 85 positions and compare if byte in position len - 85 is equal to hex 0x2. Does anybody know what am I doing wrong?, As tcpdump does not complain when executing that command, but the filter when attached to my C program does not work I am attaching that code with setsockopt(2) - SO_ATTACH_FILTER sudo tcpdump 'ether [ len ] - 85 = 0x2' -dd { 0x80, 0, 0, 0x00000000 }, { 0x7, 0, 0, 0x00000000 }, { 0x50, 0, 0, 0x00000000 }, { 0x14, 0, 0, 0x00000055 }, { 0x54, 0, 0, 0x000000ff }, { 0x15, 0, 1, 0x00000002 }, { 0x6, 0, 0, 0x0000ffff }, { 0x6, 0, 0, 0x00000000 }, Thanks! From owner-freebsd-net@freebsd.org Thu Jan 7 17:36:49 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 725B0A65A2D for ; Thu, 7 Jan 2016 17:36:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 636F61D80 for ; Thu, 7 Jan 2016 17:36:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u07HamHd038792 for ; Thu, 7 Jan 2016 17:36:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 168246] [em] Multiple legacy em(4) not working with qemu Date: Thu, 07 Jan 2016 17:36:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.0-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:36:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D168246 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed --- Comment #5 from Sean Bruno --- Tested with the latest FreeBSD11 snapshot and emulators/qemu-devel from por= ts and this all seems to work just fine now. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jan 7 17:39:28 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3354FA65BFC for ; Thu, 7 Jan 2016 17:39:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2410C107A for ; Thu, 7 Jan 2016 17:39:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u07HdSND042159 for ; Thu, 7 Jan 2016 17:39:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 185427] [igb] [panic] freebsd 8.4, 9.1 and 9.2 panic Double-Fault with intel 82576 igb driver Date: Thu, 07 Jan 2016 17:39:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:39:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D185427 --- Comment #6 from Sean Bruno --- This may be a 32bit specific failure case here. We'll have to try and buil= d up an i386 system and test. This doesn't happen on any of my amd64 hosts. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jan 7 17:43:29 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AAEF9A65E98 for ; Thu, 7 Jan 2016 17:43:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B28F15D0 for ; Thu, 7 Jan 2016 17:43:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u07HhTo2053528 for ; Thu, 7 Jan 2016 17:43:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 163903] [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABLE Date: Thu, 07 Jan 2016 17:43:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.0-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Unable to Reproduce X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:43:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D163903 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Unable to Reproduce Status|In Progress |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jan 7 17:51:57 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F478A6627D for ; Thu, 7 Jan 2016 17:51:57 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DFB41B89 for ; Thu, 7 Jan 2016 17:51:57 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3pbw9j22mQz1TC for ; Thu, 7 Jan 2016 18:51:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1452189109; x=1454781110; bh=8F+ 3CYHvpbGETS2Y5qXCJZ9EaWSzHfvB8/TNjcRPlsM=; b=oOidWRGAqjswEMaUVKj R4BP/MscrTR9yMDgrb5KTZyIf1l2p7I/TX9GxH3r+p8KnK/J8lmtm5FHu6vR1lMe OgAE/moInVi76JEdOp0hfv+aZ/xAQEmrMuei60IP6bAKIY5MnyTeS53qqOqOFBKx XhoyMto91rvNwEoCEsu9B9io= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id 7SnWdy4Zja-t for ; Thu, 7 Jan 2016 18:51:49 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3pbw9d5rj0z1T8 for ; Thu, 7 Jan 2016 18:51:49 +0100 (CET) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3pbw9d3LSxzgg for ; Thu, 7 Jan 2016 18:51:49 +0100 (CET) Received: from neli.ijs.si (2001:1470:ff80:88:21c:c0ff:feb1:8c91) by nabiralnik.ijs.si with HTTP (HTTP/1.1 POST); Thu, 07 Jan 2016 18:51:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 07 Jan 2016 18:51:49 +0100 From: Mark Martinec To: freebsd-net@freebsd.org Subject: Re: 250x slowdown on localhost sockets with certain sized write(2) call from perl Organization: Jozef Stefan Institute In-Reply-To: <2392D9E1-CA83-42F2-A3C9-DFF63772539F@mailermailer.com> References: <2392D9E1-CA83-42F2-A3C9-DFF63772539F@mailermailer.com> Message-ID: <7d1d6d177b4996758bf23b440c3b63da@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.1.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:51:57 -0000 This is how TCP works by default (delayed ACK, Nagle). See: http://marc.info/?t=132173691400053&r=1&w=2 Mark On 2016-01-07 18:03, Vick Khera wrote: > I noticed a very curious slowdown in submitting email via a perl > program to a mail server running on the same host. I narrowed it down > to messages which were exactly 16332 bytes or shorted. Once they hit > 16333 bytes, they submit extremely fast. This slowdown only affects > connections on the local host. Connections to a remote mail server are > unaffected. > > I’m not 100% sure if this is a bug in FreeBSD or in Perl’s Net::SMTP > module, but the smallest test case I could come up with is below. My > hunch is that it is FreeBSD’s bug because I cannot reproduce this > problem on several linux versions. > > > How to reproduce it: > > In window A, run "smtp-sink -c -4 :8025 10" with the smtp-sink program > from Postfix. Alternatively, run the "perl-sink" program below, which > requires the p5-Net-SMTP-Server package. You really don’t want to > point the test program at a real mail server, though it does the same > slowdown with postfix when sending a hand-crafted message of the right > size. > > In window B, run "perl standalone-smtp-speed.pl". On my FreeBSD 9.3 > and 10.2 systems, this output looks consistently like this: > > length=16327 elapsed = 0.106297 **SLOW > length=16328 elapsed = 0.108077 **SLOW > length=16329 elapsed = 0.101655 **SLOW > length=16330 elapsed = 0.106082 **SLOW > length=16331 elapsed = 0.10716 **SLOW > length=16332 elapsed = 0.106499 **SLOW > length=16333 elapsed = 0.00041 > length=16334 elapsed = 0.00041 > length=16335 elapsed = 0.000415 > length=16336 elapsed = 0.000367 > > That is, up until the time the length of the message hits 16333 bytes, > it is about 250 times slower to send the message to the mail server. > It does not matter how many before or after messages are sent or what > their lengths are, it is always that length threshold that causes a > material shift in the time it takes. > > Perl’s SMTP send ultimately ends up calling syswrite() from perl, > which is write(2) from C. This is where the slowness comes, it seems. > The syswrite() always completes with one call — no retries are > necessary for short writes. > > If you update the standalone-smtp-speed.pl script to point to the sink > program on a different host, all the lengths run fast. > > I tried to make a test case that just uses syswrite() directly without > the SMTP module, but I couldn’t do it. Maybe it requires some data to > be received too. I don’t know. > > Any ideas as to why? The only clue I found was this kernel PR > referencing the number 16332 as the length of partial writes to a > socket. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173309 > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Thu Jan 7 18:29:38 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B8E2A66F7B for ; Thu, 7 Jan 2016 18:29:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C24C1CDB for ; Thu, 7 Jan 2016 18:29:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u07ITbE7014265 for ; Thu, 7 Jan 2016 18:29:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 185427] [igb] [panic] freebsd 8.4, 9.1 and 9.2 panic Double-Fault with intel 82576 igb driver Date: Thu, 07 Jan 2016 18:29:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@grosbein.net X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 18:29:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D185427 eugen@grosbein.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eugen@grosbein.net --- Comment #7 from eugen@grosbein.net --- (In reply to napTu from comment #5) These crashes do not seem igb-specific for me. It seems, you run something like mpd daemon serving lots of users with NAT = and Netflow processing, do you? If so, have you applied some non-default system tuning? Specifically, what is your sysctl net.isr.dispatch setting for this router? It is generally not recommended to run busy mpd servers with 32 bit FreeBSD version due to stability problems even if a router has less that 4GB RAM. Have you read my notes on the topic (in Russian) http://dadv.livejournal.com/137221.html ? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jan 7 18:31:16 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C24CA6700C for ; Thu, 7 Jan 2016 18:31:16 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 CA5251E06 for ; Thu, 7 Jan 2016 18:31:15 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lb0-x234.google.com with SMTP id pv2so228174448lbb.1 for ; Thu, 07 Jan 2016 10:31:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=50oKhdfKCHgPNs7K9T+r5KFkvi5/KNIMQaU9bhEdHBc=; b=0sueSVCwnOD/1+UYTvcLm8qFcbGZ/CDoj5O6QWsflXFYd/UsKmCIgDCD4o/jvTyRyE F6fRbcLA6MOFowz5EmtEK7F1by/9kYBdjDyjr2l6ORLP7QGzuVRxEklfuRCqcZ2w0SHZ sJKi5BP0Xk7z7fdpnHgcM+ttrDo+cK264iAUeh4Qbq2XdM9EVQHPujkrQUjo9j8HhWr2 s0md7+bdd/qcTli6OwT35JYx7+zeo/atwcwY0Xxjczn1bMq5+Edv+sY+hUN5AiAqMkBo XRPhdO4acmCrOVqCOzNRiHxXhW+qzC/X/G29ykxyISYgR5mdgIF9pJNPewC8IlVPjr0m Sz/A== MIME-Version: 1.0 X-Received: by 10.112.50.134 with SMTP id c6mr39138233lbo.14.1452191473609; Thu, 07 Jan 2016 10:31:13 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.13.33 with HTTP; Thu, 7 Jan 2016 10:31:13 -0800 (PST) In-Reply-To: <20160107161213.GZ3625@kib.kiev.ua> References: <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107161213.GZ3625@kib.kiev.ua> Date: Thu, 7 Jan 2016 10:31:13 -0800 X-Google-Sender-Auth: Ykny7dAFWgJmXZpXSJleZu4FZSI Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Luigi Rizzo To: Konstantin Belousov Cc: Boris Astardzhiev , Mark Delany , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 18:31:16 -0000 On Thu, Jan 7, 2016 at 8:12 AM, Konstantin Belousov wrote: > On Thu, Jan 07, 2016 at 03:29:23PM +0200, Boris Astardzhiev wrote: >> >What are the reasons to go with the trivial kernel implementation >> >right now, instead of trivial and simpler libc wrapper ? I think the >> >speed would be same, but the code _much_ simpler. >> >> My initial idea was such that with the kernel approach we get closer to the >> driver itself and if it has mm optimizations we may have a benefit in >> future. >> And thus one day we won't need to redo the work scrubbing the libc-only >> implementation. > > I suspect that the actual syscall interface would be more rich than the > direct translation of the function signature into the syscall. IMO it > would be easier for you to get the pure libc implementation correct > for the first step. > > With such changes, I alway much prefer to have the hard part prototyped > before making the bound changes in the API/ABI, which in this case means > that some protocol should be enchanced to the multi-message interface. While it was good to have the first patch as a reminder of what needs to be done (noticeably, discuss the various pieces to be modified and how to deal with errors and the comments about DoS and malloc), I think that at the moment it is premature to implement either the library functions or the syscalls. What we need first is experimental data that shows a performance benefit compared to looping around the single-packet syscall. Then we can decide how to proceed. Implementing the library function now is relatively pointless: its only use would be to compile some software that requires *mmsg() , and we can address that with a custom patch for the application (which almost surely would need to work around another ton of linux-specific functions). Implementing the syscall that just reflects the libc function, as Kostantin rightly commented, may be too limited, and we cannot tell until we know what solution permits achieving decent performance improvements, especially on the send side -- e.g. some argument to tell the syscall "there are more packets coming down so please hold on a bit". For receive, there is probably very little room for enhancements, the best we can do is grab everything from the socket. cheers luigi -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@freebsd.org Thu Jan 7 19:28:47 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70810A66550 for ; Thu, 7 Jan 2016 19:28:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1712214D9 for ; Thu, 7 Jan 2016 19:28:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u07JSg1x025056 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 21:28:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u07JSg1x025056 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u07JSesd025055; Thu, 7 Jan 2016 21:28:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 7 Jan 2016 21:28:40 +0200 From: Konstantin Belousov To: Luigi Rizzo Cc: Boris Astardzhiev , Mark Delany , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160107192840.GF3625@kib.kiev.ua> References: <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107161213.GZ3625@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 19:28:47 -0000 On Thu, Jan 07, 2016 at 10:31:13AM -0800, Luigi Rizzo wrote: > While it was good to have the first patch as a reminder of what needs to be done > (noticeably, discuss the various pieces to be modified and how to deal > with errors and the comments about DoS and malloc), I think that at > the moment it is premature to implement either the library functions > or the syscalls. > > What we need first is experimental data that shows a performance benefit > compared to looping around the single-packet syscall. Then we can decide > how to proceed. This is about performance. > > Implementing the library function now is relatively pointless: its only use > would be to compile some software that requires *mmsg() , and we can address > that with a custom patch for the application (which almost surely would > need to work around another ton of linux-specific functions). And this is about compatibility. I agree with the statement above about the work with the performance motivation, but I do not agree that we should not ensure compatibility because there is more to do. We have willing contributor, who learns, and who is on track to provide a usable implementation for the compat shims, be it in userspace or kernel (I do prefer userspace implementation). I do not understand you point that we can patch application. IMO it is not a useful or scalable approach to handle changing app expectations from the base platform. > > Implementing the syscall that just reflects the libc function, as Kostantin > rightly commented, may be too limited, and we cannot tell until we know > what solution permits achieving decent performance improvements, > especially on the send side -- e.g. some argument to tell the syscall > "there are more packets coming down so please hold on a bit". > For receive, there is probably very little room for enhancements, > the best we can do is grab everything from the socket. Yes, this is an argument for two things: to make libc wrapper, and to measure kernel variant, as an option. From owner-freebsd-net@freebsd.org Thu Jan 7 19:46:38 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DFE9A66DEA for ; Thu, 7 Jan 2016 19:46:38 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 0C74215E5 for ; Thu, 7 Jan 2016 19:46:37 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x22e.google.com with SMTP id c192so162728362lfe.2 for ; Thu, 07 Jan 2016 11:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GBsdg0ZcSVolHiZCxs6XxsTcw4n+O5MqDjpWDQkL3EU=; b=jN1KfVzM5FH3ElrcfzFdfzBGMUnpavjq8MDUtZAxb4TMg3mTb6VxZIbXXb5Gig7Ghl udipw9hYcyjBqKkoPb2sj26zkun+p0T5cX4/hMou5V+IpV5X8FL+DQklzFr2vlVtVX5t U4LvdPpcPEoEdNz8MRrig3meOt1yuUGx9fNBpEKmEtuI9CGMqPAQbt/rFLlJxKRn1XIT 77oEpL30uf8nCCLQ1O6Yt0gQ0rGjTgX4oPriVqTzwJ1DMnwr/D+KxCK/rAFJEtLMso0/ Mw17XTHv0tLkkIPVFP8ik4yTvnrjp7iymAq20r5wG3lEb9I278iv7dlY7O2o9p/ZXmPJ llIQ== MIME-Version: 1.0 X-Received: by 10.25.89.193 with SMTP id n184mr39463095lfb.28.1452195996130; Thu, 07 Jan 2016 11:46:36 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.13.33 with HTTP; Thu, 7 Jan 2016 11:46:35 -0800 (PST) In-Reply-To: <20160107192840.GF3625@kib.kiev.ua> References: <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107161213.GZ3625@kib.kiev.ua> <20160107192840.GF3625@kib.kiev.ua> Date: Thu, 7 Jan 2016 11:46:35 -0800 X-Google-Sender-Auth: whEZFnuQb6rfNxrFgu-wVxZIhiY Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Luigi Rizzo To: Konstantin Belousov Cc: Boris Astardzhiev , Mark Delany , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 19:46:38 -0000 On Thu, Jan 7, 2016 at 11:28 AM, Konstantin Belousov wrote: > On Thu, Jan 07, 2016 at 10:31:13AM -0800, Luigi Rizzo wrote: >> While it was good to have the first patch as a reminder of what needs to be done >> (noticeably, discuss the various pieces to be modified and how to deal >> with errors and the comments about DoS and malloc), I think that at >> the moment it is premature to implement either the library functions >> or the syscalls. >> >> What we need first is experimental data that shows a performance benefit >> compared to looping around the single-packet syscall. Then we can decide >> how to proceed. > This is about performance. > >> >> Implementing the library function now is relatively pointless: its only use >> would be to compile some software that requires *mmsg() , and we can address >> that with a custom patch for the application (which almost surely would >> need to work around another ton of linux-specific functions). > And this is about compatibility. I agree with the statement above about > the work with the performance motivation, but I do not agree that we should > not ensure compatibility because there is more to do. We have willing > contributor, who learns, and who is on track to provide a usable > implementation for the compat shims, be it in userspace or kernel (I do > prefer userspace implementation). > > I do not understand you point that we can patch application. IMO it > is not a useful or scalable approach to handle changing app expectations > from the base platform. The libc API obviously needs to be conforming to the existing sendmmsg/recvmmsg. I thought your point was that the underlying syscall might possibly need a different set of parameters, so we could as well experiment a bit to see what is needed before freezing it. Regarding patching the application(s): of course it is not scalable if there are many applications that will refuse to compile if the *mmsg() functions are absent. However I expect this set of application to be minuscule if not empty, and if they exist they are probably plagued by other portability issues. So (and using *mmsg() vs *msg() is about performance) I think that until we have an underlying performant implementation of the *mmsg() calls, there is no urgency in implementing the libc functions, because we might later have to change then libc->syscall wrapper anyways. cheers luigi From owner-freebsd-net@freebsd.org Thu Jan 7 20:02:18 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D50CA675FF for ; Thu, 7 Jan 2016 20:02:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 073C01944 for ; Thu, 7 Jan 2016 20:02:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u07K2DHf033361 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 22:02:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u07K2DHf033361 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u07K2B9f033360; Thu, 7 Jan 2016 22:02:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 7 Jan 2016 22:02:11 +0200 From: Konstantin Belousov To: Luigi Rizzo Cc: Boris Astardzhiev , Mark Delany , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160107200211.GG3625@kib.kiev.ua> References: <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107161213.GZ3625@kib.kiev.ua> <20160107192840.GF3625@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 20:02:18 -0000 On Thu, Jan 07, 2016 at 11:46:35AM -0800, Luigi Rizzo wrote: > The libc API obviously needs to be conforming to the existing > sendmmsg/recvmmsg. I thought your point was that the underlying > syscall might possibly need a different set of parameters, so we could > as well experiment a bit to see what is needed before freezing it. Right, this is a correct representation of my position. This is why I do not want to provide a kernel interface for backing the functions. > > Regarding patching the application(s): of course it is not scalable > if there are many applications that will refuse to compile if > the *mmsg() functions are absent. However I expect this set of > application to be minuscule if not empty, and if they exist they > are probably plagued by other portability issues. I have an opposite impression. I think people who proposed the addition of the API, should weight in there. > > So (and using *mmsg() vs *msg() is about performance) I think that > until we have an underlying performant implementation of the *mmsg() > calls, there is no urgency in implementing the libc functions, > because we might later have to change then libc->syscall wrapper > anyways. If only libc functions are implemented, with the loop in usermode, we do not need any syscall layer and can provide whatever tilt in the kernel interface which would be found by experiments. From owner-freebsd-net@freebsd.org Thu Jan 7 22:38:29 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BE8DA67792 for ; Thu, 7 Jan 2016 22:38:29 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: from f5.bushwire.net (f5.bushwire.net [199.48.133.46]) by mx1.freebsd.org (Postfix) with ESMTP id C5CC31092 for ; Thu, 7 Jan 2016 22:38:28 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: by f5.bushwire.net (Postfix, from userid 1001) id 73872AC909; Thu, 7 Jan 2016 14:38:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2015; t=1452206301; bh=GI4S1OKfUFtIBZxBHlllBewZXN4=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=yLNEBu0pz217K+J0BAfErKeyzgVJcoVZUQkm1FQrzKrm8LKRpARXp4T87KLvSKbGB ApaTqTvCnGLNu0JcusC4dSAflLwG9b1ECOltF8JHLH4bVhBNCOXI8G6J8LVjx1FTM1 Yqhu/v0izeWZ7LNk1FBS+uikjG4OZUjxJ/mi4qZU=i4qZU= Comments: QMDA 0.3 Received: (qmail 39497 invoked by uid 1001); 7 Jan 2016 22:38:21 -0000 Date: 7 Jan 2016 22:38:21 +0000 Message-ID: <20160107223821.39496.qmail@f5-external.bushwire.net> From: "Mark Delany" To: "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? References: <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107161213.GZ3625@kib.kiev.ua> <20160107192840.GF3625@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 22:38:29 -0000 On 07Jan16, Luigi Rizzo allegedly wrote: > On Thu, Jan 7, 2016 at 11:28 AM, Konstantin Belousov > Regarding patching the application(s): of course it is not scalable > if there are many applications that will refuse to compile if > the *mmsg() functions are absent. However I expect this set of > application to be minuscule if not empty, and if they exist they > are probably plagued by other portability issues. The most common use I've seen is in DNS servers - all of which compile on the dominant *nix platforms already. Some have also done their own variant of a *mmsg() wrapper. nsd is one public example - though I believe they found problems with the linux implementation. My guess is that people stumble across the *mmsg() calls and consider adding them to an already-portable piece of code before finding they don't exist on FBSD. Leastwise that's my experience. > So (and using *mmsg() vs *msg() is about performance) I think that > until we have an underlying performant implementation of the *mmsg() > calls, there is no urgency in implementing the libc functions, > because we might later have to change then libc->syscall wrapper > anyways. Doesn't this present a bit of a chicken-and-egg problem? In two ways. First, there is pretty low visibility (and credibility since they are Linux-only) for these calls so programmers may not even be structuring their code with batching in mind. Second and more serious is that a libc implementation doesn't really get any closer to a code-base that can be used to experiment with performance whereas a kernel-based implementation does. I agree with your assessment that real gains require much more than just a kernel-side loop but my experience is that very real gains should be possible in the long run based on a) observed significant kernel serialization in UDP and b) comparisons with an *mmsg() wrapper implemented on top of netmap. I also observe that there are modest gains to be had even in kernel-side wrappers so adoption seems probably. I also completely understand your caution as there is a general case for a batching I/O mechanism that is better suited to threaded programs (one big problem being the disconnect between event detection and data transfer.) But that's a much bigger discussion so it's hard to know whether tinkering with the libc/kernel interface of *mmsg() will realistically get us closer to that or whether it's more pragmatic to treat *mmsg() as yet another specialized interface. Mark. From owner-freebsd-net@freebsd.org Thu Jan 7 22:45:18 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18AF5A67AC9 for ; Thu, 7 Jan 2016 22:45:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0856617A3 for ; Thu, 7 Jan 2016 22:45:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u07MjHLB086546 for ; Thu, 7 Jan 2016 22:45:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202875] ixv driver in 11.0-CURRENT doesn't pass traffic using KVM hypervisor Date: Thu, 07 Jan 2016 22:45:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking, needs-qa, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jlpetz@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 22:45:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D202875 --- Comment #11 from Jarrod Petz --- Looks like the diff has been committed. So this Bugzilla can probably be resolved now? https://reviews.freebsd.org/D4186 https://reviews.freebsd.org/rS292674 I am resolving the separate Bug I raised for Xen. As the above diff along w= ith this one below resolved my issue. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D202983 https://reviews.freebsd.org/D4788 https://reviews.freebsd.org/rS293338 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jan 7 22:47:22 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 722C4A67B78 for ; Thu, 7 Jan 2016 22:47:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61B4C1A09 for ; Thu, 7 Jan 2016 22:47:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u07MlMkv089118 for ; Thu, 7 Jan 2016 22:47:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202983] ixv driver in 11.0-CURRENT(10.1 & 10.2 RELEASE) doesn't pass traffic using XEN hypervisor(AWS EC2) Date: Thu, 07 Jan 2016 22:47:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jlpetz@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 22:47:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D202983 Jarrod Petz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED --- Comment #6 from Jarrod Petz --- I am resolving this, the commits below have fixed FreeBSD CURRENT/11 and 10 will be fixed if these get MFC'ed. https://reviews.freebsd.org/D4186 https://reviews.freebsd.org/rS292674 https://reviews.freebsd.org/D4788 https://reviews.freebsd.org/rS293338 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jan 7 23:15:32 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 203D2A666DC for ; Thu, 7 Jan 2016 23:15:32 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 9E2EE1F85 for ; Thu, 7 Jan 2016 23:15:31 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x232.google.com with SMTP id m198so17978388lfm.0 for ; Thu, 07 Jan 2016 15:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PRmCR0OCKmIwTU2Iphd3yaqlK8t3w5r3fK/njFaFavs=; b=XV2WuZkK4g4F9MtLMMp2DHonlS+LsdfESiKtxrcJ+VBfDrN2Jy7rzFOYNEffiaapqm 2EdOU1ZVMdqYPskMYWP/Kdn4GNcXsgVzWZIfRxQBXYGFKmQsGyihHvWJ2KnHf0fvojXk RKdxXWeEWZ3ryiZ2ZEoM8C4GK/yeEJPoMCDnvlFa6chPHc4xrE4hs3dh2lRJlVlu7K4k g+ZTsv459Jlcvzr37SGfmOUYTf59ra9FNNoxaOuG+400ZJP5w0piW1gPmWn4mDkWLDaw +DFx1vXCedaXQczGq8bccns4c3JKIUEzjBGC/e6xOCC8heRLqJ1OTKJkJyjrwNKAwIYZ q5TQ== MIME-Version: 1.0 X-Received: by 10.25.22.72 with SMTP id m69mr23049746lfi.37.1452208529474; Thu, 07 Jan 2016 15:15:29 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.13.33 with HTTP; Thu, 7 Jan 2016 15:15:29 -0800 (PST) In-Reply-To: <20160107223821.39496.qmail@f5-external.bushwire.net> References: <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107161213.GZ3625@kib.kiev.ua> <20160107192840.GF3625@kib.kiev.ua> <20160107223821.39496.qmail@f5-external.bushwire.net> Date: Thu, 7 Jan 2016 15:15:29 -0800 X-Google-Sender-Auth: WPTtHeCP1IQPA54ES6ML5u6enBo Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Luigi Rizzo To: Mark Delany Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 23:15:32 -0000 On Thu, Jan 7, 2016 at 2:38 PM, Mark Delany wrote: > On 07Jan16, Luigi Rizzo allegedly wrote: >> On Thu, Jan 7, 2016 at 11:28 AM, Konstantin Belousov >> So (and using *mmsg() vs *msg() is about performance) I think that >> until we have an underlying performant implementation of the *mmsg() >> calls, there is no urgency in implementing the libc functions, >> because we might later have to change then libc->syscall wrapper >> anyways. > > Doesn't this present a bit of a chicken-and-egg problem? Actually I'd like to see data that show the performance gain before going and implementing the new functions. Of course someone has to experiment with them (and I wish I had the time, but now I don't), but that does not imply putting the code in the main FreeBSD tree. Whoever has the time and expertise to do the necessary implementation and testing of the proper kernel side (and application restructuring) will take zero time to also write the libc wrapper. I don't want to be negative but when (3 years ago) played with sendmmsg() on linux the benefits were marginal if measurable at all. Also I want to add one bit of information here. Restructuring applications so that they use batching is very complicated, because it has to happen at all layers. An approach that we used with good results in the past (back in 2013 when we added netmap support to Qemu, and then later for bhyve) is add a flag to the API so a producer can signal that more packets are coming and each layer can construct a batch. https://lists.gnu.org/archive/html/qemu-devel/2013-12/msg01091.html The change was not accepted in qemu "does not help in linux". Sure enough, one year later linux added a similar thing with a big fanfare https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=35a9ad8af0b This is probably the way to go for achieving high tx speeds, adding support for the flag in the layers of the network stack and probably also to sendmsg() . cheers luigi > > In two ways. First, there is pretty low visibility (and credibility > since they are Linux-only) for these calls so programmers may not even > be structuring their code with batching in mind. > > Second and more serious is that a libc implementation doesn't really > get any closer to a code-base that can be used to experiment with > performance whereas a kernel-based implementation does. > > I agree with your assessment that real gains require much more than > just a kernel-side loop but my experience is that very real gains > should be possible in the long run based on a) observed significant > kernel serialization in UDP and b) comparisons with an *mmsg() wrapper > implemented on top of netmap. > > I also observe that there are modest gains to be had even in > kernel-side wrappers so adoption seems probably. > > I also completely understand your caution as there is a general case > for a batching I/O mechanism that is better suited to threaded > programs (one big problem being the disconnect between event detection > and data transfer.) > > But that's a much bigger discussion so it's hard to know whether > tinkering with the libc/kernel interface of *mmsg() will realistically > get us closer to that or whether it's more pragmatic to treat *mmsg() > as yet another specialized interface. > > > Mark. > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@freebsd.org Fri Jan 8 01:36:40 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A697A67082 for ; Fri, 8 Jan 2016 01:36:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C6C31BC2 for ; Fri, 8 Jan 2016 01:36:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u081adUE052670 for ; Fri, 8 Jan 2016 01:36:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203524] TCP checksum failed on igb network adapter Date: Fri, 08 Jan 2016 01:36:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: erj@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 01:36:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203524 Eric Joyner changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Not A Bug Status|New |Closed CC| |erj@freebsd.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 8 01:37:11 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBB5BA670C8 for ; Fri, 8 Jan 2016 01:37:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CDF861C6E for ; Fri, 8 Jan 2016 01:37:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u081bBix053335 for ; Fri, 8 Jan 2016 01:37:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197139] Double cleanup in igb_attach Date: Fri, 08 Jan 2016 01:37:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: erj@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: erj@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 01:37:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197139 Eric Joyner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress Assignee|freebsd-net@FreeBSD.org |erj@freebsd.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 8 02:12:18 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62F64A679DA for ; Fri, 8 Jan 2016 02:12:18 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.rbsd.freebsd.org (unknown [IPv6:2607:fc50:2000:101::1bb:73]) by mx1.freebsd.org (Postfix) with ESMTP id 4641B1E3E for ; Fri, 8 Jan 2016 02:12:18 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.rbsd.freebsd.org (Postfix, from userid 1346) id 40F52331EDD8; Fri, 8 Jan 2016 02:12:18 +0000 (UTC) Date: Fri, 8 Jan 2016 02:12:18 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D4824+325+0b1ea329f3d380e8@reviews.freebsd.org Subject: [Differential] [Request, 276 lines] D4824: hyperv/hn: Implement LRO Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , Thread-Topic: D4824: hyperv/hn: Implement LRO X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk Thread-Index: MTc5M2I0ZWQ4MDNkYjdlMTJiMjY5YThlMzIw MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_fb8f18771ce435cb4febbc9532fb01a6" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 02:12:18 -0000 --b1_fb8f18771ce435cb4febbc9532fb01a6 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit sepherosa_gmail.com created this revision. sepherosa_gmail.com added reviewers: adrian, delphij, royger, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, kmacy. sepherosa_gmail.com added a subscriber: freebsd-net-list. REVISION SUMMARY - Implement the LRO using tcp_lro APIs, and LRO is enabled by default - Add several stats sysctl nodes - Check IP/TCP length before sending the packet to tcp_lro_rx(), if host does not provide RX csum information (*); and add an option through sysctl to always trust host TCP segment csum checks (default is off). - Add sysctl to control the LRO entry depth. This depends on later tcp_lro patch, thus it is disabled by default. It is used to avoid holding too much TCP segments in driver. Limiting the LRO entry depth helps a lot in a one/two streams RX test. This one 3x the RX performance on my local test (3Gbps -> 10Gbps), and ~2x the RX performance over a directly connected 40Ge network (5Gbps -> 9Gbps). Reviewed by: Hongjiang Zhang , Dexuan Cui , Jun Su Tested by: me (local), Hongjiang Zhang (directly connected 40Ge) Sponsored by: Microsoft OSTC REVISION DETAIL https://reviews.freebsd.org/D4824 AFFECTED FILES sys/dev/hyperv/netvsc/hv_net_vsc.c sys/dev/hyperv/netvsc/hv_net_vsc.h sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c sys/dev/hyperv/netvsc/hv_rndis.h sys/dev/hyperv/netvsc/hv_rndis_filter.c sys/dev/hyperv/netvsc/hv_rndis_filter.h EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, adrian, delphij, royger, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, kmacy Cc: freebsd-net-list --b1_fb8f18771ce435cb4febbc9532fb01a6 Content-Type: text/x-patch; charset=utf-8; name="D4824.12025.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D4824.12025.patch" ZGlmZiAtLWdpdCBhL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9ybmRpc19maWx0ZXIuaCBiL3N5 cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9ybmRpc19maWx0ZXIuaAotLS0gYS9zeXMvZGV2L2h5cGVy di9uZXR2c2MvaHZfcm5kaXNfZmlsdGVyLmgKKysrIGIvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2 X3JuZGlzX2ZpbHRlci5oCkBAIC05OCw2ICs5OCw3IEBACiAKIGludCBodl9yZl9vbl9yZWNlaXZl KG5ldHZzY19kZXYgKm5ldF9kZXYsCiAgICAgc3RydWN0IGh2X2RldmljZSAqZGV2aWNlLCBuZXR2 c2NfcGFja2V0ICpwa3QpOwordm9pZCBodl9yZl9yZWNlaXZlX3JvbGx1cChuZXR2c2NfZGV2ICpu ZXRfZGV2KTsKIGludCBodl9yZl9vbl9kZXZpY2VfYWRkKHN0cnVjdCBodl9kZXZpY2UgKmRldmlj ZSwgdm9pZCAqYWRkaXRsX2luZm8pOwogaW50IGh2X3JmX29uX2RldmljZV9yZW1vdmUoc3RydWN0 IGh2X2RldmljZSAqZGV2aWNlLCBib29sZWFuX3QgZGVzdHJveV9jaGFubmVsKTsKIGludCBodl9y Zl9vbl9vcGVuKHN0cnVjdCBodl9kZXZpY2UgKmRldmljZSk7CmRpZmYgLS1naXQgYS9zeXMvZGV2 L2h5cGVydi9uZXR2c2MvaHZfcm5kaXNfZmlsdGVyLmMgYi9zeXMvZGV2L2h5cGVydi9uZXR2c2Mv aHZfcm5kaXNfZmlsdGVyLmMKLS0tIGEvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X3JuZGlzX2Zp bHRlci5jCisrKyBiL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9ybmRpc19maWx0ZXIuYwpAQCAt OTYzLDMgKzk2MywxNCBAQAogCXJlcXVlc3QtPmhhbHRfY29tcGxldGVfZmxhZyA9IDE7CiB9CiAK Ky8qCisgKiBSTkRJUyBmaWx0ZXIgd2hlbiAiYWxsIiByZWNlcHRpb24gaXMgZG9uZQorICovCit2 b2lkCitodl9yZl9yZWNlaXZlX3JvbGx1cChuZXR2c2NfZGV2ICpuZXRfZGV2KQoreworCXJuZGlz X2RldmljZSAqcm5kaXNfZGV2OworCisJcm5kaXNfZGV2ID0gKHJuZGlzX2RldmljZSAqKW5ldF9k ZXYtPmV4dGVuc2lvbjsKKwluZXR2c2NfcmVjdl9yb2xsdXAocm5kaXNfZGV2LT5uZXRfZGV2LT5k ZXYpOworfQpkaWZmIC0tZ2l0IGEvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X3JuZGlzLmggYi9z eXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfcm5kaXMuaAotLS0gYS9zeXMvZGV2L2h5cGVydi9uZXR2 c2MvaHZfcm5kaXMuaAorKysgYi9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfcm5kaXMuaApAQCAt MTA0OSw2ICsxMDQ5LDcgQEAKIGludCBuZXR2c2NfcmVjdihzdHJ1Y3QgaHZfZGV2aWNlICpkZXZp Y2VfY3R4LCAKICAgICBuZXR2c2NfcGFja2V0ICpwYWNrZXQsIAogICAgIHJuZGlzX3RjcF9pcF9j c3VtX2luZm8gKmNzdW1faW5mbyk7Cit2b2lkIG5ldHZzY19yZWN2X3JvbGx1cChzdHJ1Y3QgaHZf ZGV2aWNlICpkZXZpY2VfY3R4KTsKIAogdm9pZCogaHZfc2V0X3JwcGlfZGF0YShybmRpc19tc2cg KnJuZGlzX21lc2csCiAgICAgdWludDMyX3QgcnBwaV9zaXplLApkaWZmIC0tZ2l0IGEvc3lzL2Rl di9oeXBlcnYvbmV0dnNjL2h2X25ldHZzY19kcnZfZnJlZWJzZC5jIGIvc3lzL2Rldi9oeXBlcnYv bmV0dnNjL2h2X25ldHZzY19kcnZfZnJlZWJzZC5jCi0tLSBhL3N5cy9kZXYvaHlwZXJ2L25ldHZz Yy9odl9uZXR2c2NfZHJ2X2ZyZWVic2QuYworKysgYi9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZf bmV0dnNjX2Rydl9mcmVlYnNkLmMKQEAgLTY5LDYgKzY5LDcgQEAKICNpbmNsdWRlIDxzeXMvcXVl dWUuaD4KICNpbmNsdWRlIDxzeXMvbG9jay5oPgogI2luY2x1ZGUgPHN5cy9zeC5oPgorI2luY2x1 ZGUgPHN5cy9zeXNjdGwuaD4KIAogI2luY2x1ZGUgPG5ldC9pZi5oPgogI2luY2x1ZGUgPG5ldC9p Zl9hcnAuaD4KQEAgLTEzOCw2ICsxMzksMTUgQEAKICAgICBDU1VNX0lQX0lTQ1NJfENTVU1fSVA2 X1VEUHxDU1VNX0lQNl9UQ1B8Q1NVTV9JUDZfU0NUUHwJCVwKICAgICBDU1VNX0lQNl9UU098Q1NV TV9JUDZfSVNDU0kpCiAKKy8qIFhYWCBtb3ZlIHRvIG5ldGluZXQvdGNwX2xyby5oICovCisjZGVm aW5lIEhOX0xST19ISVdBVF9NQVgJCQkJNjU1MzUKKyNkZWZpbmUgSE5fTFJPX0hJV0FUX0RFRgkJ CQlITl9MUk9fSElXQVRfTUFYCisvKiBZWVkgMipNVFUgaXMgYSBiaXQgcm91Z2gsIGJ1dCBzaG91 bGQgYmUgZ29vZCBlbm91Z2guICovCisjZGVmaW5lIEhOX0xST19ISVdBVF9NVFVMSU0oaWZwKQkJ CSgyICogKGlmcCktPmlmX210dSkKKyNkZWZpbmUgSE5fTFJPX0hJV0FUX0lTVkFMSUQoc2MsIGhp d2F0KQkJCVwKKyAgICAoKGhpd2F0KSA+PSBITl9MUk9fSElXQVRfTVRVTElNKChzYyktPmhuX2lm cCkgfHwJXAorICAgICAoaGl3YXQpIDw9IEhOX0xST19ISVdBVF9NQVgpCisKIC8qCiAgKiBEYXRh IHR5cGVzCiAgKi8KQEAgLTE3MSw2ICsxODEsOSBAQAogLyogVGhlIG9uZSBhbmQgb25seSBvbmUg Ki8KIHN0YXRpYyBzdHJ1Y3QgaHZfbmV0dnNjX2RyaXZlcl9jb250ZXh0IGdfbmV0dnNjX2RydjsK IAorLyogVHJ1c3QgdGNwIHNlZ2VtZW50cyB2ZXJpZmljYXRpb24gb24gaG9zdCBzaWRlLiAqLwor c3RhdGljIGludCBobl90cnVzdF9ob3N0dGNwID0gMDsKK1RVTkFCTEVfSU5UKCJkZXYuaG4udHJ1 c3RfaG9zdHRjcCIsICZobl90cnVzdF9ob3N0dGNwKTsKIAogLyoKICAqIEZvcndhcmQgZGVjbGFy YXRpb25zCkBAIC0xODEsNiArMTk0LDE5IEBACiBzdGF0aWMgaW50ICBobl9pb2N0bChzdHJ1Y3Qg aWZuZXQgKmlmcCwgdV9sb25nIGNtZCwgY2FkZHJfdCBkYXRhKTsKIHN0YXRpYyBpbnQgIGhuX3N0 YXJ0X2xvY2tlZChzdHJ1Y3QgaWZuZXQgKmlmcCk7CiBzdGF0aWMgdm9pZCBobl9zdGFydChzdHJ1 Y3QgaWZuZXQgKmlmcCk7CisjaWZkZWYgSE5fTFJPX0hJV0FUCitzdGF0aWMgaW50IGhuX2xyb19o aXdhdF9zeXNjdGwoU1lTQ1RMX0hBTkRMRVJfQVJHUyk7CisjZW5kaWYKK3N0YXRpYyBpbnQgaG5f Y2hlY2tfaXBsZW4oY29uc3Qgc3RydWN0IG1idWYgKiwgaW50KTsKKworc3RhdGljIF9faW5saW5l IHZvaWQKK2huX3NldF9scm9faGl3YXQoc3RydWN0IGhuX3NvZnRjICpzYywgaW50IGhpd2F0KQor eworCXNjLT5obl9scm9faGl3YXQgPSBoaXdhdDsKKyNpZmRlZiBITl9MUk9fSElXQVQKKwlzYy0+ aG5fbHJvLmxyb19oaXdhdCA9IHNjLT5obl9scm9faGl3YXQ7CisjZW5kaWYKK30KIAogLyoKICAq IE5ldFZzYyBnZXQgbWVzc2FnZSB0cmFuc3BvcnQgcHJvdG9jb2wgdHlwZSAKQEAgLTMxMCw2ICsz MzYsOCBAQAogCWhuX3NvZnRjX3QgKnNjOwogCWludCB1bml0ID0gZGV2aWNlX2dldF91bml0KGRl dik7CiAJc3RydWN0IGlmbmV0ICppZnA7CisJc3RydWN0IHN5c2N0bF9vaWRfbGlzdCAqY2hpbGQ7 CisJc3RydWN0IHN5c2N0bF9jdHhfbGlzdCAqY3R4OwogCWludCByZXQ7CiAKIAluZXR2c2NfaW5p dCgpOwpAQCAtMzIyLDYgKzM1MCw4IEBACiAJYnplcm8oc2MsIHNpemVvZihobl9zb2Z0Y190KSk7 CiAJc2MtPmhuX3VuaXQgPSB1bml0OwogCXNjLT5obl9kZXYgPSBkZXY7CisJc2MtPmhuX2xyb19o aXdhdCA9IEhOX0xST19ISVdBVF9ERUY7CisJc2MtPmhuX3RydXN0X2hvc3R0Y3AgPSBobl90cnVz dF9ob3N0dGNwOwogCiAJTlZfTE9DS19JTklUKHNjLCAiTmV0VlNDTG9jayIpOwogCkBAIC0zNDks OSArMzc5LDExIEBACiAJICovCiAJaWZwLT5pZl9oZHJsZW4gPSBzaXplb2Yoc3RydWN0IGV0aGVy X3ZsYW5faGVhZGVyKTsKIAlpZnAtPmlmX2NhcGFiaWxpdGllcyB8PQotCSAgICBJRkNBUF9WTEFO X0hXVEFHR0lORyB8IElGQ0FQX1ZMQU5fTVRVIHwgSUZDQVBfSFdDU1VNIHwgSUZDQVBfVFNPOwor CSAgICBJRkNBUF9WTEFOX0hXVEFHR0lORyB8IElGQ0FQX1ZMQU5fTVRVIHwgSUZDQVBfSFdDU1VN IHwgSUZDQVBfVFNPIHwKKwkgICAgSUZDQVBfTFJPOwogCWlmcC0+aWZfY2FwZW5hYmxlIHw9Ci0J ICAgIElGQ0FQX1ZMQU5fSFdUQUdHSU5HIHwgSUZDQVBfVkxBTl9NVFUgfCBJRkNBUF9IV0NTVU0g fCBJRkNBUF9UU087CisJICAgIElGQ0FQX1ZMQU5fSFdUQUdHSU5HIHwgSUZDQVBfVkxBTl9NVFUg fCBJRkNBUF9IV0NTVU0gfCBJRkNBUF9UU08gfAorCSAgICBJRkNBUF9MUk87CiAJLyoKIAkgKiBP bmx5IGVuYWJsZSBVRFAgY2hlY2tzdW0gb2ZmbG9hZGluZyB3aGVuIGl0IGlzIG9uIDIwMTJSMiBv cgogCSAqIGxhdGVyLiBVRFAgY2hlY2tzdW0gb2ZmbG9hZGluZyBkb2Vzbid0IHdvcmsgb24gZWFy bGllcgpAQCAtMzcyLDggKzQwNCw0MSBAQAogCQlzYy0+aG5fY2FycmllciA9IDE7CiAJfQogCisJ dGNwX2xyb19pbml0KCZzYy0+aG5fbHJvKTsKKwkvKiBEcml2ZXIgcHJpdmF0ZSBMUk8gc2V0dGlu Z3MgKi8KKwlzYy0+aG5fbHJvLmlmcCA9IGlmcDsKKyNpZmRlZiBITl9MUk9fSElXQVQKKwlzYy0+ aG5fbHJvLmxyb19oaXdhdCA9IHNjLT5obl9scm9faGl3YXQ7CisjZW5kaWYKKwogCWV0aGVyX2lm YXR0YWNoKGlmcCwgZGV2aWNlX2luZm8ubWFjX2FkZHIpOwogCisJY3R4ID0gZGV2aWNlX2dldF9z eXNjdGxfY3R4KGRldik7CisJY2hpbGQgPSBTWVNDVExfQ0hJTERSRU4oZGV2aWNlX2dldF9zeXNj dGxfdHJlZShkZXYpKTsKKworCVNZU0NUTF9BRERfSU5UKGN0eCwgY2hpbGQsIE9JRF9BVVRPLCAi bHJvX3F1ZXVlZCIsCisJICAgIENUTEZMQUdfUkQsICZzYy0+aG5fbHJvLmxyb19xdWV1ZWQsIDAs ICJMUk8gcXVldWVkIik7CisJU1lTQ1RMX0FERF9JTlQoY3R4LCBjaGlsZCwgT0lEX0FVVE8sICJs cm9fZmx1c2hlZCIsCisJICAgIENUTEZMQUdfUkQsICZzYy0+aG5fbHJvLmxyb19mbHVzaGVkLCAw LCAiTFJPIGZsdXNoZWQiKTsKKwlTWVNDVExfQUREX1VMT05HKGN0eCwgY2hpbGQsIE9JRF9BVVRP LCAibHJvX3RyaWVkIiwKKwkgICAgQ1RMRkxBR19SVywgJnNjLT5obl9scm9fdHJpZWQsICIjIG9m IExSTyB0cmllcyIpOworI2lmZGVmIEhOX0xST19ISVdBVAorCVNZU0NUTF9BRERfUFJPQyhjdHgs IGNoaWxkLCBPSURfQVVUTywgImxyb19oaXdhdCIsCisJICAgIENUTFRZUEVfSU5UIHwgQ1RMRkxB R19SVywgc2MsIDAsIGhuX2xyb19oaXdhdF9zeXNjdGwsCisJICAgICJJIiwgIkxSTyBoaWdoIHdh dGVybWFyayIpOworI2VuZGlmCisJU1lTQ1RMX0FERF9JTlQoY3R4LCBjaGlsZCwgT0lEX0FVVE8s ICJ0cnVzdF9ob3N0dGNwIiwKKwkgICAgQ1RMRkxBR19SVywgJnNjLT5obl90cnVzdF9ob3N0dGNw LCAwLAorCSAgICAiVHJ1c3QgdGNwIHNlZ2VtZW50IHZlcmlmaWNhdGlvbiBvbiBob3N0IHNpZGUs ICIKKwkgICAgIndoZW4gY3N1bSBpbmZvIGlzIG1pc3NpbmciKTsKKwlTWVNDVExfQUREX1VMT05H KGN0eCwgY2hpbGQsIE9JRF9BVVRPLCAiY3N1bV9pcCIsCisJICAgIENUTEZMQUdfUlcsICZzYy0+ aG5fY3N1bV9pcCwgIlJYQ1NVTSBJUCIpOworCVNZU0NUTF9BRERfVUxPTkcoY3R4LCBjaGlsZCwg T0lEX0FVVE8sICJjc3VtX3RjcCIsCisJICAgIENUTEZMQUdfUlcsICZzYy0+aG5fY3N1bV90Y3As ICJSWENTVU0gVENQIik7CisJU1lTQ1RMX0FERF9VTE9ORyhjdHgsIGNoaWxkLCBPSURfQVVUTywg ImNzdW1fdHJ1c3RlZCIsCisJICAgIENUTEZMQUdfUlcsICZzYy0+aG5fY3N1bV90cnVzdGVkLAor CSAgICAiIyBvZiBUQ1Agc2VnZW1lbnRzIHRoYXQgd2UgdHJ1c3QgaG9zdCdzIGNzdW0gdmVyaWZp Y2F0aW9uIik7CisKIAlyZXR1cm4gKDApOwogfQogCkBAIC0zODMsNiArNDQ4LDcgQEAKIHN0YXRp YyBpbnQKIG5ldHZzY19kZXRhY2goZGV2aWNlX3QgZGV2KQogeworCXN0cnVjdCBobl9zb2Z0YyAq c2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CiAJc3RydWN0IGh2X2RldmljZSAqaHZfZGV2aWNl ID0gdm1idXNfZ2V0X2RldmN0eChkZXYpOyAKIAogCWlmIChib290dmVyYm9zZSkKQEAgLTQwMSw2 ICs0NjcsOCBAQAogCiAJaHZfcmZfb25fZGV2aWNlX3JlbW92ZShodl9kZXZpY2UsIEhWX1JGX05W X0RFU1RST1lfQ0hBTk5FTCk7CiAKKwl0Y3BfbHJvX2ZyZWUoJnNjLT5obl9scm8pOworCiAJcmV0 dXJuICgwKTsKIH0KIApAQCAtODg3LDcgKzk1NSw3IEBACiAJc3RydWN0IG1idWYgKm1fbmV3Owog CXN0cnVjdCBpZm5ldCAqaWZwOwogCWRldmljZV90IGRldiA9IGRldmljZV9jdHgtPmRldmljZTsK LQlpbnQgc2l6ZTsKKwlpbnQgc2l6ZSwgZG9fbHJvID0gMDsKIAogCWlmIChzYyA9PSBOVUxMKSB7 CiAJCXJldHVybiAoMCk7IC8qIFRPRE86IEtZUyBob3cgY2FuIHRoaXMgYmUhICovCkBAIC05Mzgs MTYgKzEwMDYsNTggQEAKIAkJaWYgKGNzdW1faW5mby0+cmVjZWl2ZS5pcF9jc3VtX3N1Y2NlZWRl ZCkgewogCQkJbV9uZXctPm1fcGt0aGRyLmNzdW1fZmxhZ3MgfD0KIAkJCSAgICAoQ1NVTV9JUF9D SEVDS0VEIHwgQ1NVTV9JUF9WQUxJRCk7CisJCQlzYy0+aG5fY3N1bV9pcCsrOwogCQl9CiAKIAkJ LyogVENQIGNzdW0gb2ZmbG9hZCAqLwogCQlpZiAoY3N1bV9pbmZvLT5yZWNlaXZlLnRjcF9jc3Vt X3N1Y2NlZWRlZCkgewogCQkJbV9uZXctPm1fcGt0aGRyLmNzdW1fZmxhZ3MgfD0KIAkJCSAgICAo Q1NVTV9EQVRBX1ZBTElEIHwgQ1NVTV9QU0VVRE9fSERSKTsKIAkJCW1fbmV3LT5tX3BrdGhkci5j c3VtX2RhdGEgPSAweGZmZmY7CisJCQlzYy0+aG5fY3N1bV90Y3ArKzsKKwkJfQorCisJCWlmIChj c3VtX2luZm8tPnJlY2VpdmUuaXBfY3N1bV9zdWNjZWVkZWQgJiYKKwkJICAgIGNzdW1faW5mby0+ cmVjZWl2ZS50Y3BfY3N1bV9zdWNjZWVkZWQpCisJCQlkb19scm8gPSAxOworCX0gZWxzZSB7CisJ CWNvbnN0IHN0cnVjdCBldGhlcl9oZWFkZXIgKmVoOworCQl1aW50MTZfdCBldHlwZTsKKwkJaW50 IGhvZmY7CisKKwkJaG9mZiA9IHNpemVvZigqZWgpOworCQlpZiAobV9uZXctPm1fbGVuIDwgaG9m ZikKKwkJCWdvdG8gc2tpcDsKKwkJZWggPSBtdG9kKG1fbmV3LCBzdHJ1Y3QgZXRoZXJfaGVhZGVy ICopOworCQlldHlwZSA9IG50b2hzKGVoLT5ldGhlcl90eXBlKTsKKwkJaWYgKGV0eXBlID09IEVU SEVSVFlQRV9WTEFOKSB7CisJCQljb25zdCBzdHJ1Y3QgZXRoZXJfdmxhbl9oZWFkZXIgKmV2bDsK KworCQkJaG9mZiA9IHNpemVvZigqZXZsKTsKKwkJCWlmIChtX25ldy0+bV9sZW4gPCBob2ZmKQor CQkJCWdvdG8gc2tpcDsKKwkJCWV2bCA9IG10b2QobV9uZXcsIHN0cnVjdCBldGhlcl92bGFuX2hl YWRlciAqKTsKKwkJCWV0eXBlID0gbnRvaHMoZXZsLT5ldmxfcHJvdG8pOwogCQl9Ci0JfQogCisJ CWlmIChldHlwZSA9PSBFVEhFUlRZUEVfSVApIHsKKwkJCWludCBwcjsKKworCQkJcHIgPSBobl9j aGVja19pcGxlbihtX25ldywgaG9mZik7CisJCQlpZiAocHIgPT0gSVBQUk9UT19UQ1ApIHsKKwkJ CQlpZiAoc2MtPmhuX3RydXN0X2hvc3R0Y3ApIHsKKwkJCQkJc2MtPmhuX2NzdW1fdHJ1c3RlZCsr OworCQkJCQltX25ldy0+bV9wa3RoZHIuY3N1bV9mbGFncyB8PQorCQkJCQkgICAoQ1NVTV9JUF9D SEVDS0VEIHwgQ1NVTV9JUF9WQUxJRCB8CisJCQkJCSAgICBDU1VNX0RBVEFfVkFMSUQgfCBDU1VN X1BTRVVET19IRFIpOworCQkJCQltX25ldy0+bV9wa3RoZHIuY3N1bV9kYXRhID0gMHhmZmZmOwor CQkJCX0KKwkJCQkvKiBSZWx5IG9uIFNXIGNzdW0gdmVyaWZpY2F0aW9uIHRob3VnaC4uLiAqLwor CQkJCWRvX2xybyA9IDE7CisJCQl9CisJCX0KKwl9Citza2lwOgogCWlmICgocGFja2V0LT52bGFu X3RjaSAhPSAwKSAmJgogCSAgICAoaWZwLT5pZl9jYXBlbmFibGUgJiBJRkNBUF9WTEFOX0hXVEFH R0lORykgIT0gMCkgewogCQltX25ldy0+bV9wa3RoZHIuZXRoZXJfdnRhZyA9IHBhY2tldC0+dmxh bl90Y2k7CkBAIC05NjEsMTIgKzEwNzEsMzcgQEAKIAogCWlmX2luY19jb3VudGVyKGlmcCwgSUZD T1VOVEVSX0lQQUNLRVRTLCAxKTsKIAorCWlmICgoaWZwLT5pZl9jYXBlbmFibGUgJiBJRkNBUF9M Uk8pICYmIGRvX2xybykgeworCQlzdHJ1Y3QgbHJvX2N0cmwgKmxybyA9ICZzYy0+aG5fbHJvOwor CisJCWlmIChscm8tPmxyb19jbnQpIHsKKwkJCXNjLT5obl9scm9fdHJpZWQrKzsKKwkJCWlmICh0 Y3BfbHJvX3J4KGxybywgbV9uZXcsIDApID09IDApIHsKKwkJCQkvKiBET05FISAqLworCQkJCXJl dHVybiAwOworCQkJfQorCQl9CisJfQorCiAJLyogV2UncmUgbm90IGhvbGRpbmcgdGhlIGxvY2sg aGVyZSwgc28gZG9uJ3QgcmVsZWFzZSBpdCAqLwogCSgqaWZwLT5pZl9pbnB1dCkoaWZwLCBtX25l dyk7CiAKIAlyZXR1cm4gKDApOwogfQogCit2b2lkCituZXR2c2NfcmVjdl9yb2xsdXAoc3RydWN0 IGh2X2RldmljZSAqZGV2aWNlX2N0eCkKK3sKKwlobl9zb2Z0Y190ICpzYyA9IGRldmljZV9nZXRf c29mdGMoZGV2aWNlX2N0eC0+ZGV2aWNlKTsKKwlzdHJ1Y3QgbHJvX2N0cmwgKmxybyA9ICZzYy0+ aG5fbHJvOworCXN0cnVjdCBscm9fZW50cnkgKnF1ZXVlZDsKKworCXdoaWxlICgocXVldWVkID0g U0xJU1RfRklSU1QoJmxyby0+bHJvX2FjdGl2ZSkpICE9IE5VTEwpIHsKKwkJU0xJU1RfUkVNT1ZF X0hFQUQoJmxyby0+bHJvX2FjdGl2ZSwgbmV4dCk7CisJCXRjcF9scm9fZmx1c2gobHJvLCBxdWV1 ZWQpOworCX0KK30KKwogLyoKICAqIFJ1bGVzIGZvciB1c2luZyBzYy0+dGVtcF91bnVzYWJsZToK ICAqIDEuICBzYy0+dGVtcF91bnVzYWJsZSBjYW4gb25seSBiZSByZWFkIG9yIHdyaXR0ZW4gd2hp bGUgaG9sZGluZyBOVl9MT0NLKCkKQEAgLTEwMjIsNyArMTE1NywxMyBAQAogCiAJCS8qIE9idGFp biBhbmQgcmVjb3JkIHJlcXVlc3RlZCBNVFUgKi8KIAkJaWZwLT5pZl9tdHUgPSBpZnItPmlmcl9t dHU7Ci0gCQkKKwkJLyoKKwkJICogTWFrZSBzdXJlIHRoYXQgTFJPIGhpZ2ggd2F0ZXJtYXJrIGlz IHN0aWxsIHZhbGlkLAorCQkgKiBhZnRlciBNVFUgY2hhbmdlICh0aGUgMipNVFUgbGltaXQpLgor CQkgKi8KKwkJaWYgKCFITl9MUk9fSElXQVRfSVNWQUxJRChzYywgc2MtPmhuX2xyb19oaXdhdCkp CisJCQlobl9zZXRfbHJvX2hpd2F0KHNjLCBITl9MUk9fSElXQVRfTVRVTElNKGlmcCkpOworCiAJ CWRvIHsKIAkJCU5WX0xPQ0soc2MpOwogCQkJaWYgKCFzYy0+dGVtcF91bnVzYWJsZSkgewpAQCAt MTE0Nyw2ICsxMjg4LDggQEAKIAkJCQlpZnAtPmlmX2NhcGVuYWJsZSB8PSBJRkNBUF9SWENTVU07 CiAJCQl9CiAJCX0KKwkJaWYgKG1hc2sgJiBJRkNBUF9MUk8pCisJCQlpZnAtPmlmX2NhcGVuYWJs ZSBePSBJRkNBUF9MUk87CiAKIAkJaWYgKG1hc2sgJiBJRkNBUF9UU080KSB7CiAJCQlpZnAtPmlm X2NhcGVuYWJsZSBePSBJRkNBUF9UU080OwpAQCAtMTI5Miw2ICsxNDM1LDEwMiBAQAogfQogI2Vu ZGlmCiAKKyNpZmRlZiBITl9MUk9fSElXQVQKK3N0YXRpYyBpbnQKK2huX2xyb19oaXdhdF9zeXNj dGwoU1lTQ1RMX0hBTkRMRVJfQVJHUykKK3sKKwlzdHJ1Y3QgaG5fc29mdGMgKnNjID0gYXJnMTsK KwlpbnQgaGl3YXQsIGVycm9yOworCisJaGl3YXQgPSBzYy0+aG5fbHJvX2hpd2F0OworCWVycm9y ID0gc3lzY3RsX2hhbmRsZV9pbnQob2lkcCwgJmhpd2F0LCAwLCByZXEpOworCWlmIChlcnJvciB8 fCByZXEtPm5ld3B0ciA9PSBOVUxMKQorCQlyZXR1cm4gZXJyb3I7CisKKwlpZiAoIUhOX0xST19I SVdBVF9JU1ZBTElEKHNjLCBoaXdhdCkpCisJCXJldHVybiBFSU5WQUw7CisKKwlpZiAoc2MtPmhu X2xyb19oaXdhdCAhPSBoaXdhdCkKKwkJaG5fc2V0X2xyb19oaXdhdChzYywgaGl3YXQpOworCXJl dHVybiAwOworfQorI2VuZGlmCS8qIEhOX0xST19ISVdBVCAqLworCitzdGF0aWMgaW50Citobl9j aGVja19pcGxlbihjb25zdCBzdHJ1Y3QgbWJ1ZiAqbSwgaW50IGhvZmYpCit7CisJY29uc3Qgc3Ry dWN0IGlwICppcDsKKwlpbnQgbGVuLCBpcGhsZW4sIGlwbGVuOworCWNvbnN0IHN0cnVjdCB0Y3Bo ZHIgKnRoOworCWludCB0aG9mZjsJCQkJLyogVENQIGRhdGEgb2Zmc2V0ICovCisKKwlsZW4gPSBo b2ZmICsgc2l6ZW9mKHN0cnVjdCBpcCk7CisKKwkvKiBUaGUgcGFja2V0IG11c3QgYmUgYXQgbGVh c3QgdGhlIHNpemUgb2YgYW4gSVAgaGVhZGVyLiAqLworCWlmIChtLT5tX3BrdGhkci5sZW4gPCBs ZW4pCisJCXJldHVybiBJUFBST1RPX0RPTkU7CisKKwkvKiBUaGUgZml4ZWQgSVAgaGVhZGVyIG11 c3QgcmVzaWRlIGNvbXBsZXRlbHkgaW4gdGhlIGZpcnN0IG1idWYuICovCisJaWYgKG0tPm1fbGVu IDwgbGVuKQorCQlyZXR1cm4gSVBQUk9UT19ET05FOworCisJaXAgPSBtdG9kbyhtLCBob2ZmKTsK KworCS8qIEJvdW5kIGNoZWNrIHRoZSBwYWNrZXQncyBzdGF0ZWQgSVAgaGVhZGVyIGxlbmd0aC4g Ki8KKwlpcGhsZW4gPSBpcC0+aXBfaGwgPDwgMjsKKwlpZiAoaXBobGVuIDwgc2l6ZW9mKHN0cnVj dCBpcCkpCQkvKiBtaW5pbXVtIGhlYWRlciBsZW5ndGggKi8KKwkJcmV0dXJuIElQUFJPVE9fRE9O RTsKKworCS8qIFRoZSBmdWxsIElQIGhlYWRlciBtdXN0IHJlc2lkZSBjb21wbGV0ZWx5IGluIHRo ZSBvbmUgbWJ1Zi4gKi8KKwlpZiAobS0+bV9sZW4gPCBob2ZmICsgaXBobGVuKQorCQlyZXR1cm4g SVBQUk9UT19ET05FOworCisJaXBsZW4gPSBudG9ocyhpcC0+aXBfbGVuKTsKKworCS8qCisJICog Q2hlY2sgdGhhdCB0aGUgYW1vdW50IG9mIGRhdGEgaW4gdGhlIGJ1ZmZlcnMgaXMgYXMKKwkgKiBh dCBsZWFzdCBtdWNoIGFzIHRoZSBJUCBoZWFkZXIgd291bGQgaGF2ZSB1cyBleHBlY3QuCisJICov CisJaWYgKG0tPm1fcGt0aGRyLmxlbiA8IGhvZmYgKyBpcGxlbikKKwkJcmV0dXJuIElQUFJPVE9f RE9ORTsKKworCS8qCisJICogSWdub3JlIElQIGZyYWdtZW50cy4KKwkgKi8KKwlpZiAobnRvaHMo aXAtPmlwX29mZikgJiAoSVBfT0ZGTUFTSyB8IElQX01GKSkKKwkJcmV0dXJuIElQUFJPVE9fRE9O RTsKKworCS8qCisJICogVGhlIFRDUC9JUCBvciBVRFAvSVAgaGVhZGVyIG11c3QgYmUgZW50aXJl bHkgY29udGFpbmVkIHdpdGhpbgorCSAqIHRoZSBmaXJzdCBmcmFnbWVudCBvZiBhIHBhY2tldC4K KwkgKi8KKwlzd2l0Y2ggKGlwLT5pcF9wKSB7CisJY2FzZSBJUFBST1RPX1RDUDoKKwkJaWYgKGlw bGVuIDwgaXBobGVuICsgc2l6ZW9mKHN0cnVjdCB0Y3BoZHIpKQorCQkJcmV0dXJuIElQUFJPVE9f RE9ORTsKKwkJaWYgKG0tPm1fbGVuIDwgaG9mZiArIGlwaGxlbiArIHNpemVvZihzdHJ1Y3QgdGNw aGRyKSkKKwkJCXJldHVybiBJUFBST1RPX0RPTkU7CisJCXRoID0gKGNvbnN0IHN0cnVjdCB0Y3Bo ZHIgKikoKGNvbnN0IHVpbnQ4X3QgKilpcCArIGlwaGxlbik7CisJCXRob2ZmID0gdGgtPnRoX29m ZiA8PCAyOworCQlpZiAodGhvZmYgPCBzaXplb2Yoc3RydWN0IHRjcGhkcikgfHwgdGhvZmYgKyBp cGhsZW4gPiBpcGxlbikKKwkJCXJldHVybiBJUFBST1RPX0RPTkU7CisJCWlmIChtLT5tX2xlbiA8 IGhvZmYgKyBpcGhsZW4gKyB0aG9mZikKKwkJCXJldHVybiBJUFBST1RPX0RPTkU7CisJCWJyZWFr OworCWNhc2UgSVBQUk9UT19VRFA6CisJCWlmIChpcGxlbiA8IGlwaGxlbiArIHNpemVvZihzdHJ1 Y3QgdWRwaGRyKSkKKwkJCXJldHVybiBJUFBST1RPX0RPTkU7CisJCWlmIChtLT5tX2xlbiA8IGhv ZmYgKyBpcGhsZW4gKyBzaXplb2Yoc3RydWN0IHVkcGhkcikpCisJCQlyZXR1cm4gSVBQUk9UT19E T05FOworCQlicmVhazsKKwlkZWZhdWx0OgorCQlpZiAoaXBsZW4gPCBpcGhsZW4pCisJCQlyZXR1 cm4gSVBQUk9UT19ET05FOworCQlicmVhazsKKwl9CisJcmV0dXJuIGlwLT5pcF9wOworfQorCiBz dGF0aWMgZGV2aWNlX21ldGhvZF90IG5ldHZzY19tZXRob2RzW10gPSB7CiAgICAgICAgIC8qIERl dmljZSBpbnRlcmZhY2UgKi8KICAgICAgICAgREVWTUVUSE9EKGRldmljZV9wcm9iZSwgICAgICAg ICBuZXR2c2NfcHJvYmUpLApkaWZmIC0tZ2l0IGEvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X25l dF92c2MuaCBiL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXRfdnNjLmgKLS0tIGEvc3lzL2Rl di9oeXBlcnYvbmV0dnNjL2h2X25ldF92c2MuaAorKysgYi9zeXMvZGV2L2h5cGVydi9uZXR2c2Mv aHZfbmV0X3ZzYy5oCkBAIC00Myw2ICs0Myw4IEBACiAjaW5jbHVkZSA8c3lzL2xvY2suaD4KICNp bmNsdWRlIDxzeXMvbWFsbG9jLmg+CiAjaW5jbHVkZSA8c3lzL3N4Lmg+CisjaW5jbHVkZSA8bmV0 aW5ldC9pbi5oPgorI2luY2x1ZGUgPG5ldGluZXQvdGNwX2xyby5oPgogCiAjaW5jbHVkZSA8ZGV2 L2h5cGVydi9pbmNsdWRlL2h5cGVydi5oPgogCkBAIC05OTMsNiArOTk1LDE3IEBACiAJaW50ICAg ICAgICAgICAgIHRlbXBfdW51c2FibGU7CiAJc3RydWN0IGh2X2RldmljZSAgKmhuX2Rldl9vYmo7 CiAJbmV0dnNjX2RldiAgCSpuZXRfZGV2OworCisJc3RydWN0IGxyb19jdHJsCWhuX2xybzsKKwlp bnQJCWhuX2xyb19oaXdhdDsKKworCS8qIFRydXN0IHRjcCBzZWdtZW50cyB2ZXJpZmljYXRpb24g b24gaG9zdCBzaWRlICovCisJaW50CQlobl90cnVzdF9ob3N0dGNwOworCisJdV9sb25nCQlobl9j c3VtX2lwOworCXVfbG9uZwkJaG5fY3N1bV90Y3A7CisJdV9sb25nCQlobl9jc3VtX3RydXN0ZWQ7 CisJdV9sb25nCQlobl9scm9fdHJpZWQ7CiB9IGhuX3NvZnRjX3Q7CiAKIApkaWZmIC0tZ2l0IGEv c3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X25ldF92c2MuYyBiL3N5cy9kZXYvaHlwZXJ2L25ldHZz Yy9odl9uZXRfdnNjLmMKLS0tIGEvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X25ldF92c2MuYwor KysgYi9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfbmV0X3ZzYy5jCkBAIC05MTksNiArOTE5LDcg QEAKIAkgKi8KIAlodl9udl9vbl9yZWNlaXZlX2NvbXBsZXRpb24oZGV2aWNlLCB2bV94ZmVyX3Bh Z2VfcGt0LT5kLnRyYW5zYWN0aW9uX2lkLAogCSAgICBzdGF0dXMpOworCWh2X3JmX3JlY2VpdmVf cm9sbHVwKG5ldF9kZXYpOwogfQogCiAvKgoK --b1_fb8f18771ce435cb4febbc9532fb01a6-- From owner-freebsd-net@freebsd.org Fri Jan 8 02:29:22 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 405A9A67EB0 for ; Fri, 8 Jan 2016 02:29:22 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.rbsd.freebsd.org (unknown [IPv6:2607:fc50:2000:101::1bb:73]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE3114BE for ; Fri, 8 Jan 2016 02:29:22 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.rbsd.freebsd.org (Postfix, from userid 1346) id 28073331E500; Fri, 8 Jan 2016 02:29:22 +0000 (UTC) Date: Fri, 8 Jan 2016 02:29:22 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D4825+325+15e38f1ea6d5e28b@reviews.freebsd.org Subject: [Differential] [Request, 6 lines] D4825: tcp/lro: Add network driver configurable LRO entry depth Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , Thread-Topic: D4825: tcp/lro: Add network driver configurable LRO entry depth X-Herald-Rules: <64> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk Thread-Index: NmVkZTllNGEwNGViMzMwZDAzYzdjMGY0Y2Y4 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_84e2c2d067c6c1743eb8207d957884aa" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 02:29:22 -0000 --b1_84e2c2d067c6c1743eb8207d957884aa Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit sepherosa_gmail.com created this revision. sepherosa_gmail.com added reviewers: network, adrian, delphij, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, glebius. sepherosa_gmail.com added a subscriber: freebsd-net-list. Herald added a reviewer: transport. REVISION SUMMARY When there is only tiny amount of TCP connections and the host is slow, e.g. in VM, holding too much TCP segments in an LRO entry will cause RX performance degradation. We now allow network drivers to configure how deep one LRO entry should be. https://reviews.freebsd.org/D4824 has a disabled network driver usage example. Reviewed by: Hongjiang Zhang , Dexuan Cui , Jun Su Tested by: me (local), Hongjiang Zhang (directly connected 40Ge) Sponsored by: Microsoft OSTC BTW, I think some drivers already put a limit on the # of drivers holding TCP segments, e.g. oce(4), though oce(4) does not use per-LRO entry depth. REVISION DETAIL https://reviews.freebsd.org/D4825 AFFECTED FILES sys/netinet/tcp_lro.c sys/netinet/tcp_lro.h CHANGE DETAILS diff --git a/sys/netinet/tcp_lro.h b/sys/netinet/tcp_lro.h --- a/sys/netinet/tcp_lro.h +++ b/sys/netinet/tcp_lro.h @@ -79,6 +79,7 @@ int lro_flushed; int lro_bad_csum; int lro_cnt; + int lro_hiwat; struct lro_head lro_active; struct lro_head lro_free; diff --git a/sys/netinet/tcp_lro.c b/sys/netinet/tcp_lro.c --- a/sys/netinet/tcp_lro.c +++ b/sys/netinet/tcp_lro.c @@ -77,6 +77,7 @@ lc->lro_queued = 0; lc->lro_flushed = 0; lc->lro_cnt = 0; + lc->lro_hiwat = 65535; SLIST_INIT(&lc->lro_free); SLIST_INIT(&lc->lro_active); @@ -501,7 +502,7 @@ } /* Flush now if appending will result in overflow. */ - if (le->p_len > (65535 - tcp_data_len)) { + if (le->p_len > (lc->lro_hiwat - tcp_data_len)) { SLIST_REMOVE(&lc->lro_active, le, lro_entry, next); tcp_lro_flush(lc, le); break; @@ -559,7 +560,7 @@ * If a possible next full length packet would cause an * overflow, pro-actively flush now. */ - if (le->p_len > (65535 - lc->ifp->if_mtu)) { + if (le->p_len > (lc->lro_hiwat - lc->ifp->if_mtu)) { SLIST_REMOVE(&lc->lro_active, le, lro_entry, next); tcp_lro_flush(lc, le); } else EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, network, transport, adrian, delphij, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, glebius Cc: freebsd-net-list --b1_84e2c2d067c6c1743eb8207d957884aa Content-Type: text/x-patch; charset=utf-8; name="D4825.12026.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D4825.12026.patch" ZGlmZiAtLWdpdCBhL3N5cy9uZXRpbmV0L3RjcF9scm8uaCBiL3N5cy9uZXRpbmV0L3RjcF9scm8u aAotLS0gYS9zeXMvbmV0aW5ldC90Y3BfbHJvLmgKKysrIGIvc3lzL25ldGluZXQvdGNwX2xyby5o CkBAIC03OSw2ICs3OSw3IEBACiAJaW50CQlscm9fZmx1c2hlZDsKIAlpbnQJCWxyb19iYWRfY3N1 bTsKIAlpbnQJCWxyb19jbnQ7CisJaW50CQlscm9faGl3YXQ7CiAKIAlzdHJ1Y3QgbHJvX2hlYWQJ bHJvX2FjdGl2ZTsKIAlzdHJ1Y3QgbHJvX2hlYWQJbHJvX2ZyZWU7CmRpZmYgLS1naXQgYS9zeXMv bmV0aW5ldC90Y3BfbHJvLmMgYi9zeXMvbmV0aW5ldC90Y3BfbHJvLmMKLS0tIGEvc3lzL25ldGlu ZXQvdGNwX2xyby5jCisrKyBiL3N5cy9uZXRpbmV0L3RjcF9scm8uYwpAQCAtNzcsNiArNzcsNyBA QAogCWxjLT5scm9fcXVldWVkID0gMDsKIAlsYy0+bHJvX2ZsdXNoZWQgPSAwOwogCWxjLT5scm9f Y250ID0gMDsKKwlsYy0+bHJvX2hpd2F0ID0gNjU1MzU7CiAJU0xJU1RfSU5JVCgmbGMtPmxyb19m cmVlKTsKIAlTTElTVF9JTklUKCZsYy0+bHJvX2FjdGl2ZSk7CiAKQEAgLTUwMSw3ICs1MDIsNyBA QAogCQl9CiAKIAkJLyogRmx1c2ggbm93IGlmIGFwcGVuZGluZyB3aWxsIHJlc3VsdCBpbiBvdmVy Zmxvdy4gKi8KLQkJaWYgKGxlLT5wX2xlbiA+ICg2NTUzNSAtIHRjcF9kYXRhX2xlbikpIHsKKwkJ aWYgKGxlLT5wX2xlbiA+IChsYy0+bHJvX2hpd2F0IC0gdGNwX2RhdGFfbGVuKSkgewogCQkJU0xJ U1RfUkVNT1ZFKCZsYy0+bHJvX2FjdGl2ZSwgbGUsIGxyb19lbnRyeSwgbmV4dCk7CiAJCQl0Y3Bf bHJvX2ZsdXNoKGxjLCBsZSk7CiAJCQlicmVhazsKQEAgLTU1OSw3ICs1NjAsNyBAQAogCQkgKiBJ ZiBhIHBvc3NpYmxlIG5leHQgZnVsbCBsZW5ndGggcGFja2V0IHdvdWxkIGNhdXNlIGFuCiAJCSAq IG92ZXJmbG93LCBwcm8tYWN0aXZlbHkgZmx1c2ggbm93LgogCQkgKi8KLQkJaWYgKGxlLT5wX2xl biA+ICg2NTUzNSAtIGxjLT5pZnAtPmlmX210dSkpIHsKKwkJaWYgKGxlLT5wX2xlbiA+IChsYy0+ bHJvX2hpd2F0IC0gbGMtPmlmcC0+aWZfbXR1KSkgewogCQkJU0xJU1RfUkVNT1ZFKCZsYy0+bHJv X2FjdGl2ZSwgbGUsIGxyb19lbnRyeSwgbmV4dCk7CiAJCQl0Y3BfbHJvX2ZsdXNoKGxjLCBsZSk7 CiAJCX0gZWxzZQoK --b1_84e2c2d067c6c1743eb8207d957884aa-- From owner-freebsd-net@freebsd.org Fri Jan 8 07:24:37 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFFA6A66183 for ; Fri, 8 Jan 2016 07:24:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 6F4DB19E5 for ; Fri, 8 Jan 2016 07:24:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 8F78DD619DF; Fri, 8 Jan 2016 18:24:27 +1100 (AEDT) Date: Fri, 8 Jan 2016 18:24:26 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Luigi Rizzo , Mark Delany , Boris Astardzhiev , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <20160107192840.GF3625@kib.kiev.ua> Message-ID: <20160108172323.W1815@besplex.bde.org> References: <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107161213.GZ3625@kib.kiev.ua> <20160107192840.GF3625@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=R4L+YolX c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=8vZNj04OTU8zMInQf6EA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 07:24:37 -0000 On Thu, 7 Jan 2016, Konstantin Belousov wrote: > On Thu, Jan 07, 2016 at 10:31:13AM -0800, Luigi Rizzo wrote: >> ... >> What we need first is experimental data that shows a performance benefit >> compared to looping around the single-packet syscall. Then we can decide >> how to proceed. > This is about performance. I don't really need the performance, but have done a lot of measurements of the the sendto() loop in an old version of ttcp and know how it works. It works poorly. It is very slow, and good error handling for ENOBUFS is impossible since select() doesn't work so the only ways to handle ENOBUFS are to busy-wait or to try to use a timeout that is not too long or so short that the kernel doesn't support it or it reduces to busy-waiting. All of the netrate utilities and newer versions of ttcp have similar problems. netblast produces interesting statistics by dropping packets differently. netrate tends to reach the limits of timeout granularity before producing anything interesting. Syscall overheads and other per-packet costs are enormous. I get a 10% speedup just by changing the malloc() in sendit() + getsockaddr() to a stack variable. The full 10% only occurs for the non-useful case of _dropped_ packets (ones that are passed to the driver but dropped due to ENOBUFS there). Counting dropped (output) packets is not completely useless for packet-blasting benchmarks. If the NIC can't reach line rate, then dropped packets are your main measure of spare capacity in the network stack. Network stack overheads are also enormous. They seem to have approximately doubled since FreeBSD-5. FreeBSD-5 drops packets better by peeking at the ifq early and not sending the packets down to the driver if they would be dropped there. This frees resources for doing more useful things. Another 10-20%. Batching won't help much here, except it almost requires better ENOBUFS handling which can be done much more easily in the kernel. sm@ pointed me to kttcp in /usr/src/tools. I didn't get around to trying it and it doesn't seem to have been maintained there. I thought that it tests at the driver level, but it actually loops doing sosend/receive() so it is too high level for driver testing but at about the level of kernel sendmmsg(). Anyway: - there must be an easy 10-30% to be gained by doing sendmmsg() in the kernel for just a few more than 1 message at a time - Someone should update and test kttcp. This gives a quick test for the batch performance that can be obtained without changes deep in the stack. Bruce From owner-freebsd-net@freebsd.org Fri Jan 8 07:58:16 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEE52A66E38 for ; Fri, 8 Jan 2016 07:58:16 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: from f5.bushwire.net (f5.bushwire.net [IPv6:2607:fc50:1000:5b00::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9C59A1823 for ; Fri, 8 Jan 2016 07:58:16 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: by f5.bushwire.net (Postfix, from userid 1001) id 4CF35AC909; Thu, 7 Jan 2016 23:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2015; t=1452239895; bh=IcLWCpMHi4cwNa2MJYWzhlqkIy8=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=iZfgQqBFqrt/+na1p13ZkVOOdCHNGugPlNMyTMwnRlqUO/l1rzBjjbfKqv+iStAfF C1FJiSRzDT5OhdyXX70rN8LpLzl4rMMit7RJzMrK/zeDZHCjfN5AZmtsIshq1kla+2 LvQSY+gi5QIe1CZUkKVL68XyJi6V9qTRCamWNfr0=WNfr0= Comments: QMDA 0.3 Received: (qmail 3244 invoked by uid 1001); 8 Jan 2016 07:58:15 -0000 Date: 8 Jan 2016 07:58:15 +0000 Message-ID: <20160108075815.3243.qmail@f5-external.bushwire.net> From: "Mark Delany" To: freebsd-net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? References: <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107161213.GZ3625@kib.kiev.ua> <20160107192840.GF3625@kib.kiev.ua> <20160108172323.W1815@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160108172323.W1815@besplex.bde.org> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 07:58:16 -0000 On 08Jan16, Bruce Evans allegedly wrote: > If the NIC can't reach line rate > Network stack overheads are also enormous. Bruce makes some excellent points. I challenge anyone to get line rate UDP out of FBSD (or Linux) for a 1G NIC yet alone a 10G NIC listening to a single port. It was exactly my frustration with UDP performance that led me down the path of *mmsg() and netmap. Frankly this is an opportunity for FBSD as UDP performance appears to be a neglected area. Mark. From owner-freebsd-net@freebsd.org Fri Jan 8 08:13:57 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C016BA67730 for ; Fri, 8 Jan 2016 08:13:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 8F47814E8 for ; Fri, 8 Jan 2016 08:13:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x233.google.com with SMTP id z14so52367818igp.1 for ; Fri, 08 Jan 2016 00:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fir5OMEL947U57kojoM6nH5dKMoeNOOK/ZS/mq3o8Tc=; b=bpW6gW/FVQ4m9yhnhNiQu5PMNROjWusBC7T0iN1mznv2zXkeeC48QVDaE5MAj0YQg6 OeYXk74D14yZEBxqxDebUgnFwuqYynjY7frylIXycEPcbtloAymhKe+AJMukzh7oLgqt ZIEk76VoC/jWa42EQFq6b0hQnsNCmzsaZ7mYnN0UoPUbMk0T+ITpJwpSfTukKonTHesL PKoZWKibGqFXGv9/l9AcRVQFdEvb508eiUsM5HudqLsO61qgydnOKyo9yY5Qb8X5ywXB NUzJrQB8LuyngCqjhFJ4eErVmncbg+1tF+KZbBjKK2zRTe4GXvSFtiqH78NVNxBU//6U BTkQ== MIME-Version: 1.0 X-Received: by 10.50.171.225 with SMTP id ax1mr18349494igc.61.1452240837012; Fri, 08 Jan 2016 00:13:57 -0800 (PST) Received: by 10.36.121.202 with HTTP; Fri, 8 Jan 2016 00:13:56 -0800 (PST) In-Reply-To: <20160108075815.3243.qmail@f5-external.bushwire.net> References: <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107161213.GZ3625@kib.kiev.ua> <20160107192840.GF3625@kib.kiev.ua> <20160108172323.W1815@besplex.bde.org> <20160108075815.3243.qmail@f5-external.bushwire.net> Date: Fri, 8 Jan 2016 00:13:56 -0800 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Adrian Chadd To: Mark Delany Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 08:13:57 -0000 On 7 January 2016 at 23:58, Mark Delany wrote: > On 08Jan16, Bruce Evans allegedly wrote: >> If the NIC can't reach line rate > >> Network stack overheads are also enormous. > > Bruce makes some excellent points. > > I challenge anyone to get line rate UDP out of FBSD (or Linux) for a > 1G NIC yet alone a 10G NIC listening to a single port. It was exactly > my frustration with UDP performance that led me down the path of > *mmsg() and netmap. > > Frankly this is an opportunity for FBSD as UDP performance appears to > be a neglected area. I'm there, on 16 threads. I'd rather we do it on two or three, as a lot of time is wasted in producer/consumer locking. but yeah, 500k tx/rx should be doable per CPU with only locking changes. -a -adrian > > > Mark. > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Fri Jan 8 08:57:53 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1664A676FD for ; Fri, 8 Jan 2016 08:57:53 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: from f5.bushwire.net (f5.bushwire.net [199.48.133.46]) by mx1.freebsd.org (Postfix) with ESMTP id 7F32918EA for ; Fri, 8 Jan 2016 08:57:53 +0000 (UTC) (envelope-from c2h@romeo.emu.st) Received: by f5.bushwire.net (Postfix, from userid 1001) id 866B0AC909; Fri, 8 Jan 2016 00:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2015; t=1452243471; bh=EsV84HV9BBAx2v/U1+zvTRabXSk=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=T/hqlbr5Kp/v8dfA2A9+cvnkmgY2WvvlAE2OlgFyWyDVEOeTJh5at4/GDS0UtEe6N oBCckWq9tbfuyqQVgl8oea5hsVXgQTm2XZaPG58MW13xqVETdeysiKNsp44IkzGP4L tNI7XzGuCvOwarN1dbGtwyEm6UGBP1uPIbYADlms=ADlms= Comments: QMDA 0.3 Received: (qmail 10133 invoked by uid 1001); 8 Jan 2016 08:57:51 -0000 Date: 8 Jan 2016 08:57:51 +0000 Message-ID: <20160108085751.10132.qmail@f5-external.bushwire.net> From: "Mark Delany" To: freebsd-net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? References: <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107161213.GZ3625@kib.kiev.ua> <20160107192840.GF3625@kib.kiev.ua> <20160108172323.W1815@besplex.bde.org> <20160108075815.3243.qmail@f5-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 08:57:53 -0000 On 08Jan16, Adrian Chadd allegedly wrote: > On 7 January 2016 at 23:58, Mark Delany wrote: > I'm there, on 16 threads. That's intriquing. On CURRENT? You must be doing smarter than 16 * recvmsg() or 16 * select(). What's the thread structure? > I'd rather we do it on two or three, as a lot of time is wasted in > producer/consumer locking. but yeah, 500k tx/rx should be doable per > CPU with only locking changes. Locking changes in user space or kernel space? Mark. From owner-freebsd-net@freebsd.org Fri Jan 8 09:15:14 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21435A67FA3 for ; Fri, 8 Jan 2016 09:15:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11C41112B for ; Fri, 8 Jan 2016 09:15:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u089FDSL018276 for ; Fri, 8 Jan 2016 09:15:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 185427] [igb] [panic] freebsd 8.4, 9.1 and 9.2 panic Double-Fault with intel 82576 igb driver Date: Fri, 08 Jan 2016 09:15:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: IntelNetworking, crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 09:15:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D185427 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |crash --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 8 09:31:00 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F4A9A68379 for ; Fri, 8 Jan 2016 09:31:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 903DC15F6 for ; Fri, 8 Jan 2016 09:31:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u089UxLe046138 for ; Fri, 8 Jan 2016 09:31:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins Date: Fri, 08 Jan 2016 09:31:00 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: marc@bowtie.nl X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 09:31:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193246 marc@bowtie.nl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marc@bowtie.nl --- Comment #13 from marc@bowtie.nl --- Hi,=20 just to pitch in with additional argumentation for resolution of this bug. I ran into this exact problem with openHAB, the workaround works. But as the original reporter writes, it puts of people using FreeBSD. It was also not trivial to diagnose. Cheers, Marc. --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 8 11:02:33 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3388EA686A5 for ; Fri, 8 Jan 2016 11:02:33 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id B96A5162E for ; Fri, 8 Jan 2016 11:02:32 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 26BF4D48AB6; Fri, 8 Jan 2016 22:02:27 +1100 (AEDT) Date: Fri, 8 Jan 2016 22:02:24 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Adrian Chadd cc: Mark Delany , FreeBSD Net Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: Message-ID: <20160108204606.G2420@besplex.bde.org> References: <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107161213.GZ3625@kib.kiev.ua> <20160107192840.GF3625@kib.kiev.ua> <20160108172323.W1815@besplex.bde.org> <20160108075815.3243.qmail@f5-external.bushwire.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=PfoC/XVd c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=Cyi0gIR--wBvI8ew5kYA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 11:02:33 -0000 On Fri, 8 Jan 2016, Adrian Chadd wrote: > On 7 January 2016 at 23:58, Mark Delany wrote: >> On 08Jan16, Bruce Evans allegedly wrote: >>> If the NIC can't reach line rate >> >>> Network stack overheads are also enormous. >> >> Bruce makes some excellent points. >> >> I challenge anyone to get line rate UDP out of FBSD (or Linux) for a >> 1G NIC yet alone a 10G NIC listening to a single port. It was exactly >> my frustration with UDP performance that led me down the path of >> *mmsg() and netmap. >> >> Frankly this is an opportunity for FBSD as UDP performance appears to >> be a neglected area. > > I'm there, on 16 threads. > > I'd rather we do it on two or three, as a lot of time is wasted in > producer/consumer locking. but yeah, 500k tx/rx should be doable per > CPU with only locking changes. Line rate for 1 Gbps is about 1500 kpps (small packets). With I218V2 (em), I see enormous lock contention above 3 or 4 (user) threads, and 8 are slightly slower than 1. 1 doesn't saturate the NIC, and 2 is optimal. Bruce From owner-freebsd-net@freebsd.org Fri Jan 8 13:02:40 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93CE1A68EE1; Fri, 8 Jan 2016 13:02:40 +0000 (UTC) (envelope-from peixotocassiano@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 67B051FEE; Fri, 8 Jan 2016 13:02:40 +0000 (UTC) (envelope-from peixotocassiano@gmail.com) Received: by mail-ig0-x235.google.com with SMTP id ik10so78344400igb.1; Fri, 08 Jan 2016 05:02:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kdj4HW10+onJOvd6yNF3nbue2EYFZBd+NgcrKlYLkOQ=; b=BDJU8z+DCqA86fCN2cF6+NEbraSTXq6IDIiAk2bSqGWctAceRCtpZct8xMYsodI+g+ djvXe06Lg9RPD6v0KJg0UoOEgHf0EZP11y+8kHLRS8QwMnaXiQdqXdXwf/tmIlFC4Sgn /r7QF7eqQpvRxVDf9ycqbwIKI+c0f/1kI4ZZp2+d+NmJwERpsOb/W/KCuuWNF1eIijPh /uw+KnupYOSR9VRDNv7K4433WrpuL9BC/cBAxFF1HeyTsDWvdJFnzaxzei7fQHaNJNSA eZZwSxneW++4upBqhQgbLbQibk6jcznhwDAvR+lTXbuyJ/Cs025MQ9zsy1ZpAj6Upasn 4LmQ== MIME-Version: 1.0 X-Received: by 10.50.171.200 with SMTP id aw8mr8868663igc.77.1452258159811; Fri, 08 Jan 2016 05:02:39 -0800 (PST) Received: by 10.36.108.79 with HTTP; Fri, 8 Jan 2016 05:02:39 -0800 (PST) Date: Fri, 8 Jan 2016 11:02:39 -0200 Message-ID: Subject: Looking for a Developer to fix mpd5 issue on FreeBSD From: Cassiano Peixoto To: freebsd-net@freebsd.org, freebsd-jobs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 13:02:40 -0000 Hi guys, My company would like to hire and pay a developer to fix the issue described here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114 This is issue was opened in 2014 and i believe it affects many mpd users who would like to run it with many users replacing mikrotiks pppoe servers. Please, if you are interested please get in touch. Thanks. Cassiano From owner-freebsd-net@freebsd.org Fri Jan 8 15:59:17 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E129A67B4E for ; Fri, 8 Jan 2016 15:59:17 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from mr11p00im-asmtp002.me.com (mr11p00im-asmtp002.me.com [17.110.69.253]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C1761AAB for ; Fri, 8 Jan 2016 15:59:17 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from [192.168.1.4] (c-24-6-178-251.hsd1.ca.comcast.net [24.6.178.251]) by mr11p00im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O0N00GYO5QMJU20@mr11p00im-asmtp002.me.com> for freebsd-net@freebsd.org; Fri, 08 Jan 2016 15:59:11 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-01-08_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1601080263 User-Agent: Microsoft-MacOutlook/0.0.0.151217 Date: Fri, 08 Jan 2016 07:59:09 -0800 Subject: Re: [Differential] [Request, 6 lines] D4825: tcp/lro: Add network driver configurable LRO entry depth From: Ravi Pokala Sender: "Pokala, Ravi" To: "freebsd-net@freebsd.org" Message-id: Thread-topic: [Differential] [Request, 6 lines] D4825: tcp/lro: Add network driver configurable LRO entry depth MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 15:59:17 -0000 -----Original Message----- >Date: Fri, 8 Jan 2016 02:29:22 +0000 >From: "sepherosa_gmail.com (Sepherosa Ziehau)" > >To: freebsd-net@freebsd.org >Subject: [Differential] [Request, 6 lines] D4825: tcp/lro: Add network > driver configurable LRO entry depth >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >sepherosa_gmail.com created this revision. >sepherosa_gmail.com added reviewers: network, adrian, delphij, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, glebius. >sepherosa_gmail.com added a subscriber: freebsd-net-list. >Herald added a reviewer: transport. > >REVISION SUMMARY > When there is only tiny amount of TCP connections and the host is slow, e.g. in VM, holding too much TCP segments in an LRO entry will cause RX performance degradation. We now allow network drivers to configure how deep one LRO entry should be. Forgive me if I'm missing something obvious, but this patch doesn't actually change anything - rather than hard-coding 65535, you're using lc->lro_hiwat... which is hard-coded to 65535. Right? -Ravi (rpokala@) From owner-freebsd-net@freebsd.org Fri Jan 8 17:02:38 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B70A8A68F01 for ; Fri, 8 Jan 2016 17:02:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 8448E11A0 for ; Fri, 8 Jan 2016 17:02:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x22e.google.com with SMTP id t15so55926254igr.0 for ; Fri, 08 Jan 2016 09:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y6a9E28gzhO14KGf8m7Wyipot1MMFCZydE/bP6LGzxs=; b=ohwwaGcCfC+sdaf9C6iBlDyqQZwBKWMZCbITDkJ/z1f5PyKFWOuJ+Zx3BQnVdIVLW/ F3qd7I0abWVUIRtl5JgjB7Vk+NDpjcYVIRj+qANg2KzdLFKCyZIgVK/gUUpyIQ4Yf4VM EBU5h1ezy5B7db5fjBvdEa/ji0LjfJ9NT+TAPaYNkuHBDVHjA2z6yfY2B6KCsN0Uc6hh vqkvH8idk3uyjSBvxSiPkiBOVzHWAGpXCe6AAkFoBuza9QC5DQhZE62f94INNuOl7axX yeX+zolZ9Z1ayW03TuLrKdkiMiPhQE/1asUPrdZdvBygOT39jVcl6zlvKktkI/2g30Qk kccw== MIME-Version: 1.0 X-Received: by 10.50.136.226 with SMTP id qd2mr22966351igb.37.1452272557975; Fri, 08 Jan 2016 09:02:37 -0800 (PST) Received: by 10.36.121.202 with HTTP; Fri, 8 Jan 2016 09:02:37 -0800 (PST) In-Reply-To: <20160108204606.G2420@besplex.bde.org> References: <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107161213.GZ3625@kib.kiev.ua> <20160107192840.GF3625@kib.kiev.ua> <20160108172323.W1815@besplex.bde.org> <20160108075815.3243.qmail@f5-external.bushwire.net> <20160108204606.G2420@besplex.bde.org> Date: Fri, 8 Jan 2016 09:02:37 -0800 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Adrian Chadd To: Bruce Evans Cc: Mark Delany , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 17:02:38 -0000 On 8 January 2016 at 03:02, Bruce Evans wrote: > On Fri, 8 Jan 2016, Adrian Chadd wrote: > >> On 7 January 2016 at 23:58, Mark Delany wrote: >>> >>> On 08Jan16, Bruce Evans allegedly wrote: >>>> >>>> If the NIC can't reach line rate >>> >>> >>>> Network stack overheads are also enormous. >>> >>> >>> Bruce makes some excellent points. >>> >>> I challenge anyone to get line rate UDP out of FBSD (or Linux) for a >>> 1G NIC yet alone a 10G NIC listening to a single port. It was exactly >>> my frustration with UDP performance that led me down the path of >>> *mmsg() and netmap. >>> >>> Frankly this is an opportunity for FBSD as UDP performance appears to >>> be a neglected area. >> >> >> I'm there, on 16 threads. >> >> I'd rather we do it on two or three, as a lot of time is wasted in >> producer/consumer locking. but yeah, 500k tx/rx should be doable per >> CPU with only locking changes. .. and I did mean "kernel producer/consumer locking changes." > > Line rate for 1 Gbps is about 1500 kpps (small packets). > > With I218V2 (em), I see enormous lock contention above 3 or 4 (user) > threads, and 8 are slightly slower than 1. 1 doesn't saturate the NIC, > and 2 is optimal. > The RSS support in -HEAD lets you get away with parallelising UDP streams very nicely. The framework is pretty simple (!): * drivers ask the RSS code for the RSS config and RSS hash to use, and configure the hardware appropriately; * the netisr input paths check the existence of the RSS hash and will calculte it in software if reqiured; * v4/v6 reassembly is done (at the IP level, /not/ at the protocol level) and if it needs a new RSS hash / netisr reinjection, that'll happen; * the PCB lookup code for listen sockets now allows one listen socket per RSS bucket - as the RSS / PCBGROUPS code already extended the PCB to have one PCB table per RSS bucket (as well as a global one); So: * userland code queries RSS for the CPU and RSS bucket setup; * you then create one listen socket per RSS bucket, bind it to the local thread (if you want) and tell it "you're in RSS bucket X"; * .. and then in the UDP case for local-bound sockets, the transmit/receive path does not require modifying the global PCB state, so the locking is kept per-RSS bucket, and scales linearly with the number of CPUs you have (until you hit the NIC queue limits.) https://github.com/erikarn/freebsd-rss/ and: http://adrianchadd.blogspot.com/2014/06/hacking-on-receive-side-scaling-rss-on.html http://adrianchadd.blogspot.com/2014/07/application-awareness-of-receive-side.html http://adrianchadd.blogspot.com/2014/08/receive-side-scaling-figuring-out-how.html http://adrianchadd.blogspot.com/2014/09/receive-side-scaling-testing-udp.html http://adrianchadd.blogspot.com/2014/10/more-rss-udp-tests-this-time-on-dell.html -adrian From owner-freebsd-net@freebsd.org Fri Jan 8 17:03:11 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43C18A68F69 for ; Fri, 8 Jan 2016 17:03:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 1706D1290 for ; Fri, 8 Jan 2016 17:03:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x242.google.com with SMTP id f81so5938012iof.0 for ; Fri, 08 Jan 2016 09:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qde5PyuqYEHS1R/AbapfgGhn5mJRtZCN3ye5n6vCfxY=; b=Bw70YKv/HYEZO+z6Gb+AgSh2vRGjGTLgNCBDMB+0EzLeIkKNaQ5tNJqMnyRwYRkuUO 4moWcQFOTCzcSA05A5ZctUeXbm60yoL1NFCUAfw9bQopyWe9wH2XsAJPmJaMsi236gKG ubu3AM0R+RJvhLAQd8Oa8+eENsZd04rVousRRfrWOqktdEvyIikhkLtV/tJFU7H0fLft ZYl/d+/8b6c7atmJ9wnEdC8qoQfj4DYT9ExGsiUNBrp8jT/T9AWNuxUqRBPJtZxYzxW5 bF3dvAxiPPg6sbDm8ARTFPupmHrrcge/46MZCLqzbnlnG624siu+OITYdoVyxhb/X26b 19PA== MIME-Version: 1.0 X-Received: by 10.107.10.217 with SMTP id 86mr90688485iok.75.1452272590482; Fri, 08 Jan 2016 09:03:10 -0800 (PST) Received: by 10.36.121.202 with HTTP; Fri, 8 Jan 2016 09:03:10 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Jan 2016 09:03:10 -0800 Message-ID: Subject: Re: [Differential] [Request, 6 lines] D4825: tcp/lro: Add network driver configurable LRO entry depth From: Adrian Chadd To: Ravi Pokala Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 17:03:11 -0000 On 8 January 2016 at 07:59, Ravi Pokala wrote: > -----Original Message----- > > >>Date: Fri, 8 Jan 2016 02:29:22 +0000 >>From: "sepherosa_gmail.com (Sepherosa Ziehau)" >> >>To: freebsd-net@freebsd.org >>Subject: [Differential] [Request, 6 lines] D4825: tcp/lro: Add network >> driver configurable LRO entry depth >>Message-ID: >> >>Content-Type: text/plain; charset="utf-8" >> >>sepherosa_gmail.com created this revision. >>sepherosa_gmail.com added reviewers: network, adrian, delphij, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, glebius. >>sepherosa_gmail.com added a subscriber: freebsd-net-list. >>Herald added a reviewer: transport. >> >>REVISION SUMMARY >> When there is only tiny amount of TCP connections and the host is slow, e.g. in VM, holding too much TCP segments in an LRO entry will cause RX performance degradation. We now allow network drivers to configure how deep one LRO entry should be. > > Forgive me if I'm missing something obvious, but this patch doesn't actually change anything - rather than hard-coding 65535, you're using lc->lro_hiwat... which is hard-coded to 65535. > > Right? > Right; I'm assuming their driver will twiddle this appropriately over time. -a > -Ravi (rpokala@) > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Fri Jan 8 17:04:50 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1908EA6702C for ; Fri, 8 Jan 2016 17:04:50 +0000 (UTC) (envelope-from alex.burlyga.ietf@gmail.com) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 CCC4D1395 for ; Fri, 8 Jan 2016 17:04:49 +0000 (UTC) (envelope-from alex.burlyga.ietf@gmail.com) Received: by mail-vk0-x22e.google.com with SMTP id a123so163979053vkh.1 for ; Fri, 08 Jan 2016 09:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oJ8HpAC4egMaooM5PHHf7Nbmgr96YtpyYuYQJrpvuoU=; b=zICI1qr2xkudt+kjZRJUR5626OL5CeIGWPSLb2WRbG3i/J6lN+t1TdTyl4Bxo5QHMd 9t2ck11Nhoc754fhXgRqSIgel+Gw6gnAaTBJURYXwK/RFVOuglcDb3D3w/RVOw6x51nN Gf384uUJWyDj6n+o3Ol0dd1QkjAFnpjRkIXl35Dj/hxR5atmD6qBsDO3TFoj01y6Hu6y 3Emwt7+y2wCUeL6wjicB5/ig0gtp2K0lsT99OeLrktu/i/G1StjNw6W1MrSkgMVvQLqF kDB5F5IUIPhtS3Z+BFgAmME60bKuegMrOzqRWktFayi80y1rIlAlKyYRJjyucAJrlNpD OAIA== MIME-Version: 1.0 X-Received: by 10.31.47.88 with SMTP id v85mr80196539vkv.118.1452272688761; Fri, 08 Jan 2016 09:04:48 -0800 (PST) Received: by 10.103.108.195 with HTTP; Fri, 8 Jan 2016 09:04:48 -0800 (PST) Received: by 10.103.108.195 with HTTP; Fri, 8 Jan 2016 09:04:48 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Jan 2016 09:04:48 -0800 Message-ID: Subject: Re: [Differential] [Request, 6 lines] D4825: tcp/lro: Add network driver configurable LRO entry depth From: "alex.burlyga.ietf alex.burlyga.ietf" To: Ravi Pokala Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 17:04:50 -0000 Perhaps Sephe planing to use it as a sysctl? Alex. On Jan 8, 2016 07:59, "Ravi Pokala" wrote: > -----Original Message----- > > > >Date: Fri, 8 Jan 2016 02:29:22 +0000 > >From: "sepherosa_gmail.com (Sepherosa Ziehau)" > > > >To: freebsd-net@freebsd.org > >Subject: [Differential] [Request, 6 lines] D4825: tcp/lro: Add network > > driver configurable LRO entry depth > >Message-ID: > > > >Content-Type: text/plain; charset="utf-8" > > > >sepherosa_gmail.com created this revision. > >sepherosa_gmail.com added reviewers: network, adrian, delphij, > decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, glebius. > >sepherosa_gmail.com added a subscriber: freebsd-net-list. > >Herald added a reviewer: transport. > > > >REVISION SUMMARY > > When there is only tiny amount of TCP connections and the host is slow, > e.g. in VM, holding too much TCP segments in an LRO entry will cause RX > performance degradation. We now allow network drivers to configure how > deep one LRO entry should be. > > Forgive me if I'm missing something obvious, but this patch doesn't > actually change anything - rather than hard-coding 65535, you're using > lc->lro_hiwat... which is hard-coded to 65535. > > Right? > > -Ravi (rpokala@) > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Fri Jan 8 18:35:51 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0795A67540 for ; Fri, 8 Jan 2016 18:35:51 +0000 (UTC) (envelope-from pavel.odintsov@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 C5F1918D2 for ; Fri, 8 Jan 2016 18:35:51 +0000 (UTC) (envelope-from pavel.odintsov@gmail.com) Received: by mail-ig0-x232.google.com with SMTP id z14so81210092igp.0 for ; Fri, 08 Jan 2016 10:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EbvISzAXAscv+TUxmSucB8lgExE1y8xvSJL2eIMHPC4=; b=JRH52BjyV9qzrz3klm437oOgwh9MHjyBfY8rj0DuQv11nHCsv2ZxKX3uzT45Imcuq9 zxPdpTphDbGJu0wRxKy+nDRXuqArq+sD9YKYziKkX1jXchDWUSWi9daRJikkGvT+6t9V j2/pi8oaL3q+mj33+rpaPNcuYPyQCSWIo5DvMheuMh01/QdH2zv7eqUUloQmOPjvlEmO eghjFXvknHiQEYiOjVDjkSwyN+OZM3KxfV4XLEUrxn5kuh73ZXoIShNeKhLOF/j+clIo hWCSJrJWrK0U5r2pupZXPRaZ44b5bZOF0FZgFqAKMequko+0yLobjQzv0rpiT2S0OlPF on9w== MIME-Version: 1.0 X-Received: by 10.50.30.166 with SMTP id t6mr358651igh.15.1452278151103; Fri, 08 Jan 2016 10:35:51 -0800 (PST) Received: by 10.79.36.79 with HTTP; Fri, 8 Jan 2016 10:35:51 -0800 (PST) Date: Fri, 8 Jan 2016 21:35:51 +0300 Message-ID: Subject: Netmap software interface mirror / netmap monitor From: Pavel Odintsov To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 18:35:52 -0000 Hello, Dear Community! I'm working with netmap and my application uses netmap for traffic capture. It's works really well. But I need some way to feed same data from physical interface to two or more applications. I have found this code https://github.com/luigirizzo/netmap/blob/master/sys/dev/netmap/netmap_monitor.c but could not find any docs about it. Could you help me with examples and use cases? -- Sincerely yours, Pavel Odintsov From owner-freebsd-net@freebsd.org Fri Jan 8 18:46:07 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7491EA67980 for ; Fri, 8 Jan 2016 18:46:07 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 027461EAF for ; Fri, 8 Jan 2016 18:46:07 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x22f.google.com with SMTP id c192so180691127lfe.2 for ; Fri, 08 Jan 2016 10:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GDP7tbl3uYz5n9yhOht2A6qMvwXxErauT4jiUYh1FKc=; b=fs+V5FFoDXgVCMl9sptCf2zMyYEJkZQxdXiQ1fW5PpCQsjetfDZ9xh3ehcz+1yPlSX LLPYKfKYQzxmPR4W1oImbWTq+EL+I1S4VtCcLwzZVWWmPY/Ql9F0Hxm8KtzY6ENVt8gm rlxbyzXT81XxKjAnnieH1/u0ZfP1Fbhx7rxWiUeU8DnRGOB9cEmFygpHU+3T8oF1P1dw tw/ansG6K5xyHFCNrIvjYCtFHmMO8B3vqaEbjZ7Eatk68OvafxIyYFoNn7gPv9LtPAjx NOga/ZzpKPq3WLKPWRGtQTPba07OC6FTchKTB8L0J93GjyQZPMzIThKJiXjtbIaPpneX TnHg== MIME-Version: 1.0 X-Received: by 10.25.158.136 with SMTP id h130mr29859237lfe.136.1452278763900; Fri, 08 Jan 2016 10:46:03 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.13.33 with HTTP; Fri, 8 Jan 2016 10:46:03 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Jan 2016 10:46:03 -0800 X-Google-Sender-Auth: 75mlTHSCPxZC8wn-BXhIff91KEg Message-ID: Subject: Re: Netmap software interface mirror / netmap monitor From: Luigi Rizzo To: Pavel Odintsov Cc: "freebsd-net@freebsd.org" , Giuseppe Lettieri Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 18:46:07 -0000 On Fri, Jan 8, 2016 at 10:35 AM, Pavel Odintsov wrote: > Hello, Dear Community! > > I'm working with netmap and my application uses netmap for traffic > capture. It's works really well. > > But I need some way to feed same data from physical interface to two > or more applications. > > I have found this code > https://github.com/luigirizzo/netmap/blob/master/sys/dev/netmap/netmap_monitor.c > but could not find any docs about it. > > Could you help me with examples and use cases? look at netmap_user.h, where it explains how to open a port in monitor mode. Essentially, once you have an active netmap port say netmap:ix0, you can sniff the traffic opening additional netmap ports named netmap:ix0/r (for rx traffic) or netmap:ix0/t (for tx) or even netmap:ix0/rt (for both tx and rx) Giuseppe (in Cc) can give more details cheers luigi From owner-freebsd-net@freebsd.org Fri Jan 8 19:24:32 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31006A6899E for ; Fri, 8 Jan 2016 19:24:32 +0000 (UTC) (envelope-from pavel.odintsov@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 F38511C99 for ; Fri, 8 Jan 2016 19:24:31 +0000 (UTC) (envelope-from pavel.odintsov@gmail.com) Received: by mail-io0-x232.google.com with SMTP id g73so98652645ioe.3 for ; Fri, 08 Jan 2016 11:24:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rvVr+Dm7NR/m1OHELRVuE8BzMmz5XoHe1nJdEDTnB/4=; b=bbW5cl9fxX9W2+lfzNnfUWLI7rLmYoirjWNyvsT5jJVgyG+TgnN6RXX+sM5nioGQgw D/xUf4Z9hpMbHaRBgg5JdyOmP7Bn32Y0hOPh/y+j6ksHGlKnhtLYYt86OXMTefNHRW1U 5+XJXlGXAYp7EfT0VF/FWZd5epQ/dxWAIhiWgnhGFPvV801G3y17k90KiQrBtZZtQlVe T98/T0Y7sBZb+OOYFQwSKJR9Sbvi4x0phW45AO8vvX83q9/YErBaM49pxDMQCt6lt5Td RThgchLYpZqQ83uJViX0ye0p2NEHz0e9fQsSlC3qoul6lbftOd9WDQDxQxbtfVwzcrKk 9jpg== MIME-Version: 1.0 X-Received: by 10.107.34.14 with SMTP id i14mr52160286ioi.9.1452281071400; Fri, 08 Jan 2016 11:24:31 -0800 (PST) Received: by 10.79.36.79 with HTTP; Fri, 8 Jan 2016 11:24:31 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Jan 2016 22:24:31 +0300 Message-ID: Subject: Re: Netmap software interface mirror / netmap monitor From: Pavel Odintsov To: Luigi Rizzo Cc: "freebsd-net@freebsd.org" , Giuseppe Lettieri Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 19:24:32 -0000 That's awesome! Thanks for lightning fast answer! Will check soon! On Fri, Jan 8, 2016 at 9:46 PM, Luigi Rizzo wrote: > On Fri, Jan 8, 2016 at 10:35 AM, Pavel Odintsov > wrote: >> Hello, Dear Community! >> >> I'm working with netmap and my application uses netmap for traffic >> capture. It's works really well. >> >> But I need some way to feed same data from physical interface to two >> or more applications. >> >> I have found this code >> https://github.com/luigirizzo/netmap/blob/master/sys/dev/netmap/netmap_monitor.c >> but could not find any docs about it. >> >> Could you help me with examples and use cases? > > look at netmap_user.h, where it explains how to open a port > in monitor mode. > Essentially, once you have an active netmap port say netmap:ix0, you can > sniff the traffic opening additional netmap ports named > netmap:ix0/r (for rx traffic) or netmap:ix0/t (for tx) > or even netmap:ix0/rt (for both tx and rx) > > Giuseppe (in Cc) can give more details > > cheers > luigi -- Sincerely yours, Pavel Odintsov From owner-freebsd-net@freebsd.org Fri Jan 8 23:09:07 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD6D3A68DE8 for ; Fri, 8 Jan 2016 23:09:07 +0000 (UTC) (envelope-from h.rezaee@ideatech.io) Received: from mail.ideatech.io (mail.ideatech.io [104.131.120.36]) by mx1.freebsd.org (Postfix) with ESMTP id BF45C1795 for ; Fri, 8 Jan 2016 23:09:07 +0000 (UTC) (envelope-from h.rezaee@ideatech.io) Received: from hadi-pc.my.domain (unknown [5.106.81.240]) by mail.ideatech.io (Postfix) with ESMTPSA id 77391113024 for ; Fri, 8 Jan 2016 18:03:59 -0500 (EST) To: freebsd-net@freebsd.org From: Hadi Rezaee Subject: ethernet header size X-Enigmail-Draft-Status: N1110 Message-ID: <56904059.4010806@ideatech.io> Date: Sat, 9 Jan 2016 02:33:53 +0330 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 23:09:08 -0000 Hello there, In some part of my application I need to have the Ethernet header size (ideally, using sizeof). Well I guess 'ethhdr' is not exist on FreeBSD, correct ? According to Linux definition: struct ethhdr { unsigned char h_dest[ETH_ALEN]; unsigned char h_source[ETH_ALEN]; unsigned short h_proto; } __attribute__((packed)); So, assume the ethernet header size is equal to 14, is it going to work ?! :) and if there is already a definition somewhere in system header files, so I don't have to define the size myself ? Thank you From owner-freebsd-net@freebsd.org Fri Jan 8 23:11:26 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFBE2A68E6F for ; Fri, 8 Jan 2016 23:11:26 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (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 9A23E1A23 for ; Fri, 8 Jan 2016 23:11:26 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pa0-x22a.google.com with SMTP id cy9so289274861pac.0 for ; Fri, 08 Jan 2016 15:11:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=S5TtPVqN+9gH932VLVLMj1WUGqNLoaTi4kjlPCXxHPM=; b=Gw/V9up7U2ha6dCnTsdZxlfa4rd9nqdXzIewxNPsDvSZrcezAVQ5Rm92ZFMFV3vf1u 2O30AMzYRAn2OYAN/VzEQzBdkT92qkGe+P6qbRRDa3rb4MDxCzBODLKf/5ZMu/yPi0dl la7vW02o+6L2KwxTtB56QzOvjEDss+uiQh3iMLZiMusgBmqENG+n3hNKjKnpHs2sDrug a4eYTWuBHqEEwXfqjyi+FVpwTK1rQOG287FwI9p0nByf/GpHgPyU/L9K87K8Ge6+uRbs tjB6cwh46eTkq2IGGoRlRtxs7tHUIbA02JJHtolw9BY2tyey+s2Q/vi1ZmMJ+Jlb/+pH rjiQ== X-Received: by 10.66.237.102 with SMTP id vb6mr161919917pac.133.1452294686185; Fri, 08 Jan 2016 15:11:26 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [12.32.117.8]) by smtp.googlemail.com with ESMTPSA id w82sm1627369pfi.95.2016.01.08.15.11.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jan 2016 15:11:24 -0800 (PST) Subject: Re: ethernet header size To: Hadi Rezaee , freebsd-net@freebsd.org References: <56904059.4010806@ideatech.io> From: Navdeep Parhar Message-ID: <5690421C.7040609@gmail.com> Date: Fri, 8 Jan 2016 15:11:24 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56904059.4010806@ideatech.io> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 23:11:26 -0000 sizeof(struct ether_header) On 01/08/2016 15:03, Hadi Rezaee wrote: > Hello there, > > In some part of my application I need to have the Ethernet header size > (ideally, using sizeof). > Well I guess 'ethhdr' is not exist on FreeBSD, correct ? > > According to Linux definition: > > struct ethhdr { > unsigned char h_dest[ETH_ALEN]; > unsigned char h_source[ETH_ALEN]; > unsigned short h_proto; > } __attribute__((packed)); > > So, assume the ethernet header size is equal to 14, is it going to work > ?! :) > and if there is already a definition somewhere in system header files, > so I don't have to define the size myself ? > > Thank you > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Fri Jan 8 23:20:48 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 127F8A6734A for ; Fri, 8 Jan 2016 23:20:48 +0000 (UTC) (envelope-from h.rezaee@ideatech.io) Received: from mail.ideatech.io (mail.ideatech.io [104.131.120.36]) by mx1.freebsd.org (Postfix) with ESMTP id E8E1C1ED2 for ; Fri, 8 Jan 2016 23:20:47 +0000 (UTC) (envelope-from h.rezaee@ideatech.io) Received: from hadi-pc.my.domain (unknown [5.106.81.240]) by mail.ideatech.io (Postfix) with ESMTPSA id 75135113024; Fri, 8 Jan 2016 18:20:46 -0500 (EST) Subject: Re: ethernet header size To: Navdeep Parhar , freebsd-net@freebsd.org References: <56904059.4010806@ideatech.io> <5690421C.7040609@gmail.com> From: Hadi Rezaee Message-ID: <56904449.60202@ideatech.io> Date: Sat, 9 Jan 2016 02:50:41 +0330 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <5690421C.7040609@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 23:20:48 -0000 Thank you very much Parhar ;) On 01/09/2016 02:41, Navdeep Parhar wrote: > sizeof(struct ether_header) > > > > On 01/08/2016 15:03, Hadi Rezaee wrote: >> Hello there, >> >> In some part of my application I need to have the Ethernet header size >> (ideally, using sizeof). >> Well I guess 'ethhdr' is not exist on FreeBSD, correct ? >> >> According to Linux definition: >> >> struct ethhdr { >> unsigned char h_dest[ETH_ALEN]; >> unsigned char h_source[ETH_ALEN]; >> unsigned short h_proto; >> } __attribute__((packed)); >> >> So, assume the ethernet header size is equal to 14, is it going to work >> ?! :) >> and if there is already a definition somewhere in system header files, >> so I don't have to define the size myself ? >> >> Thank you >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > -- Hadi Rezaee +98 912 1403571 IdeaTech.io From owner-freebsd-net@freebsd.org Sat Jan 9 00:36:26 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED0E5A68EF9 for ; Sat, 9 Jan 2016 00:36:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE59A17B3 for ; Sat, 9 Jan 2016 00:36:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u090aQll048469 for ; Sat, 9 Jan 2016 00:36:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206016] Changing MTU on the interface Infiniband network card (Mellanox MHQH29B-XTR) causes panic Date: Sat, 09 Jan 2016 00:36:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 00:36:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206016 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Jan 9 01:04:47 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3B18A68DAC for ; Sat, 9 Jan 2016 01:04:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E4636110E for ; Sat, 9 Jan 2016 01:04:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0914ker035682 for ; Sat, 9 Jan 2016 01:04:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206016] Changing MTU on the interface Infiniband network card (Mellanox MHQH29B-XTR) causes panic Date: Sat, 09 Jan 2016 01:04:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: admin@support.od.ua X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 01:04:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206016 Vladislav V. Prodan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED --- Comment #3 from Vladislav V. Prodan --- After reading the article https://wiki.freebsd.org/InfiniBand, I realized my error. I unload the old modules in the memory . Rebuild the world to FreeBSD 10.2-STABLE # 0: Fri Jan 8, 2016 18:45:13 EET And added to the kernel options options OFED # Infiniband protocol stack and support options SDP # Sockets Direct Protocol for infiniband options IPOIB_CM # Use connect mode ipoib device ipoib # IP over IB devices device mlx4ib # ConnectX Infiniband support device mlxen # ConnectX Ethernet support device mthca # Infinihost cards After these manipulations network card recognized by the system, it is now possible to change the IP and MTU. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Jan 9 03:37:39 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72F79A67E22 for ; Sat, 9 Jan 2016 03:37:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E79A187B; Sat, 9 Jan 2016 03:37:38 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id u093bcp8013631 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Jan 2016 19:37:38 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id u093bbdQ013630; Fri, 8 Jan 2016 19:37:37 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 8 Jan 2016 19:37:37 -0800 From: Gleb Smirnoff To: Adrian Chadd Cc: Chagin Dmitry , FreeBSD Net Subject: Re: long network segment call stack can fail Message-ID: <20160109033737.GN1906@FreeBSD.org> References: <20160106180008.GA1363@chd.heemeyer.club> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 03:37:39 -0000 On Wed, Jan 06, 2016 at 12:50:52PM -0800, Adrian Chadd wrote: A> hah, that's very pretty. The downside of a completely direct-dispatch A> network stack. :) The stack is big, but shouldn't eat 4 pages anyway. Back in the netgraph hacking times, we used to have stack exhaustion with much longer backtraces. I expect that somewhere on the list there something huge on stack. I assume Dmitry runs with -O0, this is compile that exposes stack exhaustion first. Did I guess it right, Dmitry? -- Totus tuus, Glebius. From owner-freebsd-net@freebsd.org Sat Jan 9 07:58:49 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FA37A672B4 for ; Sat, 9 Jan 2016 07:58:49 +0000 (UTC) (envelope-from dchagin@chd.heemeyer.club) Received: from heemeyer.club (heemeyer.club [108.61.204.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "heemeyer.club", Issuer "heemeyer.club" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AF941E41; Sat, 9 Jan 2016 07:58:48 +0000 (UTC) (envelope-from dchagin@chd.heemeyer.club) Received: from chd.heemeyer.club ([78.107.232.239]) by heemeyer.club (8.15.2/8.15.1) with ESMTPS id u097wcKF030792 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 9 Jan 2016 07:58:40 GMT (envelope-from dchagin@chd.heemeyer.club) X-Authentication-Warning: heemeyer.club: Host [78.107.232.239] claimed to be chd.heemeyer.club Received: from chd.heemeyer.club (localhost [127.0.0.1]) by chd.heemeyer.club (8.15.2/8.15.1) with ESMTPS id u097wbKp004118 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 9 Jan 2016 10:58:38 +0300 (MSK) (envelope-from dchagin@chd.heemeyer.club) Received: (from dchagin@localhost) by chd.heemeyer.club (8.15.2/8.15.1/Submit) id u097wbX5004117; Sat, 9 Jan 2016 10:58:37 +0300 (MSK) (envelope-from dchagin) Date: Sat, 9 Jan 2016 10:58:37 +0300 From: Chagin Dmitry To: Gleb Smirnoff Cc: Adrian Chadd , FreeBSD Net Subject: Re: long network segment call stack can fail Message-ID: <20160109075837.GA4110@chd.heemeyer.club> References: <20160106180008.GA1363@chd.heemeyer.club> <20160109033737.GN1906@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160109033737.GN1906@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 07:58:49 -0000 On Fri, Jan 08, 2016 at 07:37:37PM -0800, Gleb Smirnoff wrote: > On Wed, Jan 06, 2016 at 12:50:52PM -0800, Adrian Chadd wrote: > A> hah, that's very pretty. The downside of a completely direct-dispatch > A> network stack. :) > > The stack is big, but shouldn't eat 4 pages anyway. Back in the netgraph yeha, exctly > hacking times, we used to have stack exhaustion with much longer backtraces. > > I expect that somewhere on the list there something huge on stack. > > I assume Dmitry runs with -O0, this is compile that exposes stack > exhaustion first. Did I guess it right, Dmitry? > no, -O2 here -- Have fun! chd From owner-freebsd-net@freebsd.org Sat Jan 9 15:41:30 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3004AA6976E for ; Sat, 9 Jan 2016 15:41:30 +0000 (UTC) (envelope-from pavel.odintsov@gmail.com) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::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 0111F15FC for ; Sat, 9 Jan 2016 15:41:30 +0000 (UTC) (envelope-from pavel.odintsov@gmail.com) Received: by mail-ig0-x234.google.com with SMTP id h5so50679785igh.0 for ; Sat, 09 Jan 2016 07:41:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+AnIYxKC7WtZ+NypuTYxVpwLYp8Elw9lPNfputZ+bew=; b=S9bnxJ/OcyD7sQZtpTTT+4q6iLCPpEdgpOLdVoEU+OwVR4eCO4CRJQJrDP7abnYMbh V4pv2s9acwyHmC+uTCRzqaklueZ6spc4cVRA475t0HCmy/0cGL0nUs+MkBx2Tp+Q+qfa W53CP1GFiOx3Ix5NzfNl/aG84qt1pptioEOaUBYGmHDz+6H5jV9rxITck4rws5GQGK3S DUfS6B02HGBtTohegfHxADClFch9m23cCJBYmzqSwRDPMxAQJxJYXzKAwRyKhgavtLGP UQlwxwUuBkKwrZk0UfctfISLb3I0TUUMqMtC9Xn8VQZXOpvw0wMpmusb4lwRT9Py4qOD KqjA== MIME-Version: 1.0 X-Received: by 10.50.143.39 with SMTP id sb7mr4279603igb.37.1452354089272; Sat, 09 Jan 2016 07:41:29 -0800 (PST) Received: by 10.79.36.79 with HTTP; Sat, 9 Jan 2016 07:41:29 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Jan 2016 18:41:29 +0300 Message-ID: Subject: Re: Netmap software interface mirror / netmap monitor From: Pavel Odintsov To: Luigi Rizzo Cc: "freebsd-net@freebsd.org" , Giuseppe Lettieri Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 15:41:30 -0000 Hello! Work like a charm! I have started two pkt-gen apps in monitoring mode for main application simultaneously and got same traffic for three apps! That's awesome! Really brilliant feature! Thanks so much for your work! ./pkt-gen -i netmap:eth1/rt 703.793991 main [1930] interface is netmap:eth1/rt 703.794050 main [2050] running on 1 cpus (have 8) 703.794227 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 703.794245 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 703.794648 main [2148] mapped 334980KB at 0x7fb9dfd7d000 Receiving from netmap:eth1/rt: 1 queues, 1 threads and 1 cpus. 703.794680 main [2235] Wait 2 secs for phy reset 705.794774 main [2237] Ready... 705.794923 receiver_body [1412] reading from netmap:eth1/rt fd 3 main_fd 3 706.795880 main_thread [1720] 722.277 Kpps (723.030 Kpkts 4.485 Gbps in 1001042 usec) 15.40 avg_batch 0 min_space 707.796928 main_thread [1720] 733.192 Kpps (733.960 Kpkts 4.529 Gbps in 1001048 usec) 15.72 avg_batch 317 min_space 708.797974 main_thread [1720] 753.922 Kpps (754.710 Kpkts 4.690 Gbps in 1001045 usec) 14.45 avg_batch 328 min_space 709.799034 main_thread [1720] 726.498 Kpps (727.269 Kpkts 4.496 Gbps in 1001061 usec) 14.21 avg_batch 374 min_space ./pkt-gen -i netmap:eth1/rt 723.359000 main [1930] interface is netmap:eth1/rt 723.359062 main [2050] running on 1 cpus (have 8) 723.359258 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 723.359282 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 723.359610 main [2148] mapped 334980KB at 0x7f1e1a67e000 Receiving from netmap:eth1/rt: 1 queues, 1 threads and 1 cpus. 723.359657 main [2235] Wait 2 secs for phy reset 725.359733 main [2237] Ready... 725.359814 receiver_body [1412] reading from netmap:eth1/rt fd 3 main_fd 3 726.360884 main_thread [1720] 765.146 Kpps (765.975 Kpkts 4.794 Gbps in 1001083 usec) 10.42 avg_batch 0 min_space 727.361920 main_thread [1720] 756.678 Kpps (757.461 Kpkts 4.683 Gbps in 1001035 usec) 12.66 avg_batch 330 min_space 728.362984 main_thread [1720] 695.403 Kpps (696.144 Kpkts 4.208 Gbps in 1001065 usec) 14.78 avg_batch 298 min_space 729.364064 main_thread [1720] 693.850 Kpps (694.599 Kpkts 4.192 Gbps in 1001080 usec) 14.35 avg_batch 332 min_space 730.365101 main_thread [1720] 732.741 Kpps (733.501 Kpkts 4.519 Gbps in 1001037 usec) 9.72 avg_batch 303 min_space On Fri, Jan 8, 2016 at 10:24 PM, Pavel Odintsov wrote: > That's awesome! Thanks for lightning fast answer! Will check soon! > > On Fri, Jan 8, 2016 at 9:46 PM, Luigi Rizzo wrote: >> On Fri, Jan 8, 2016 at 10:35 AM, Pavel Odintsov >> wrote: >>> Hello, Dear Community! >>> >>> I'm working with netmap and my application uses netmap for traffic >>> capture. It's works really well. >>> >>> But I need some way to feed same data from physical interface to two >>> or more applications. >>> >>> I have found this code >>> https://github.com/luigirizzo/netmap/blob/master/sys/dev/netmap/netmap_monitor.c >>> but could not find any docs about it. >>> >>> Could you help me with examples and use cases? >> >> look at netmap_user.h, where it explains how to open a port >> in monitor mode. >> Essentially, once you have an active netmap port say netmap:ix0, you can >> sniff the traffic opening additional netmap ports named >> netmap:ix0/r (for rx traffic) or netmap:ix0/t (for tx) >> or even netmap:ix0/rt (for both tx and rx) >> >> Giuseppe (in Cc) can give more details >> >> cheers >> luigi > > > > -- > Sincerely yours, Pavel Odintsov -- Sincerely yours, Pavel Odintsov From owner-freebsd-net@freebsd.org Sat Jan 9 22:01:30 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39CA7A698E1 for ; Sat, 9 Jan 2016 22:01:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A5E41DD3 for ; Sat, 9 Jan 2016 22:01:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u09M1UHl090486 for ; Sat, 9 Jan 2016 22:01:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206053] There is a bug in kqueue support code of netmap Date: Sat, 09 Jan 2016 22:01:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 22:01:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206053 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Jan 9 23:00:49 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1213A6ABAD for ; Sat, 9 Jan 2016 23:00:49 +0000 (UTC) (envelope-from James@Lodge.me.uk) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0127.outbound.protection.outlook.com [157.55.234.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 212B315F1 for ; Sat, 9 Jan 2016 23:00:48 +0000 (UTC) (envelope-from James@Lodge.me.uk) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gavinlodge.onmicrosoft.com; s=selector1-Lodge-me-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CnsjXGU8yPQ7ptEt1r56/wnFbvYekjme8WL3Xjqp/60=; b=Dp695X7qWHpOv6fgdFzOElBw7rpQhctYO5WngH7I76Z8ocHxqDCP7J90ukjU0E8mDlHNi3DeABpdzWJqwyKJHYHVGVgIi4lKH1vddZevbJX3y6XUSJpSQqwQC+X3BJpBFHEiwpVVTpgWZZ5FWbclDar/2P1kXaofacEZ6JrW4s8= Received: from VI1PR06MB1037.eurprd06.prod.outlook.com (10.162.123.156) by VI1PR06MB1037.eurprd06.prod.outlook.com (10.162.123.156) with Microsoft SMTP Server (TLS) id 15.1.365.19; Sat, 9 Jan 2016 21:26:41 +0000 Received: from VI1PR06MB1037.eurprd06.prod.outlook.com ([10.162.123.156]) by VI1PR06MB1037.eurprd06.prod.outlook.com ([10.162.123.156]) with mapi id 15.01.0365.020; Sat, 9 Jan 2016 21:26:41 +0000 From: James Lodge To: "freebsd-net@freebsd.org" Subject: Re: vxlan interface rc.conf configuration Thread-Topic: vxlan interface rc.conf configuration Thread-Index: AQHRSxTi/RsuPtbX2U2on4TuOxMfnJ7zsUhe Date: Sat, 9 Jan 2016 21:26:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=James@Lodge.me.uk; x-originating-ip: [81.174.132.199] x-microsoft-exchange-diagnostics: 1; VI1PR06MB1037; 5:/MlJXlVyMnzcjl50YAEe6t0p2mKlovbZ0iXaGPW3bs/GS0NlXdHd5vKMzq3zgWSmmFQtwhiygu3OBh/nwoRLhLyY3rnmcadyHHENZAe9XvqzCA9kkChHpEgWnap/ZOA76ANYivDevNghnWOigyeTYQ==; 24:MZvabo3c+XNb6laRl2S5DjVZ0XBAjUApXdk/ewC+2Lv6wo1/G5lb+XjKghRvoQxohQenPKeTmpcTY9Kcaa7ht3T1HvfS8QnSSNchvRzTObI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1037; x-ms-office365-filtering-correlation-id: 3185f9bd-df39-4995-fb03-08d3193b911c x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102615245)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:VI1PR06MB1037; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1037; x-forefront-prvs: 0816F1D86E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(69234005)(189002)(199003)(107886002)(586003)(6116002)(1096002)(102836003)(5008740100001)(3846002)(80792005)(189998001)(97736004)(110136002)(1220700001)(2501003)(81156007)(16236675004)(17760045003)(5001960100002)(11100500001)(76576001)(40100003)(74482002)(122556002)(106116001)(106356001)(19580395003)(74316001)(33656002)(19627405001)(2351001)(86362001)(105586002)(19625215002)(2900100001)(87936001)(77096005)(450100001)(92566002)(2950100001)(10400500002)(18206015028)(2906002)(101416001)(5004730100002)(99936001)(5002640100001)(76176999)(54356999)(50986999)(66066001)(19627595001)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR06MB1037; H:VI1PR06MB1037.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: Lodge.me.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: Lodge.me.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2016 21:26:41.2732 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ded56ae9-7c77-4cf6-bbfd-39e6a505742d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1037 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 23:00:49 -0000 >I'd appreciate some help with vxlan interface creation at boot up. I can c= reate a vxlan interface (unicast) using >ifconfig(8) but I'm unable to work= out or find the correct rc.conf syntax. > >I can clone the interface, but cannot configure a vni or any other paramet= ers. > >This is what I have > > >rc.conf >cloned_interfaces=3D"vxlan0" >ifconfig_vxlan0=3D"vxlanid 100 vxlanlocal x.x.x.x vxlanremote x.x.x.x inet= x.x.x.x netmask x.x.x.x" > >I'm sure I'm missing something obvious, but any help gratefully received. > >Regards > >James FYI if anyone is interested, I worked out how to create a vxlan interface i= n rc.conf at boot. I'll see about updating the man pages with an example as= it wasn't very clear, atleast not to me! [😊] rc.conf create_args_vxlan0=3D"vxlanid 100 vxlanlocal x.x.x.x vxlanremote x.x.x.x" cloned_interfaces=3D"vxlan0" ifconfig_vxlan0=3D"inet x.x.x.x netmask x.x.x.x" Hope it helps someone else and saves them time. Regards James