From owner-freebsd-net@FreeBSD.ORG Sun Aug 11 04:40:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 52CE5778 for ; Sun, 11 Aug 2013 04:40:05 +0000 (UTC) (envelope-from saeedeh.motlagh@gmail.com) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9D09020FC for ; Sun, 11 Aug 2013 04:40:04 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id a16so4078255lbj.11 for ; Sat, 10 Aug 2013 21:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JotVwjHDZtBm3ruLWP2IMzEUHKwgVo1SFTnSFXqUKMg=; b=GqYk9HLj8azLndoFZhsdqAIrf8QEq3cihs8leGDDipd7UN4csBYVgDzCWVinAmNNre KNF1D5eSWRfVgd0kjcM2v/wIOGvPEdK/prAy9gH+NOiQ21mgm8wDi7mJ3G0EExb5xM/n yffIx7iTIJiqaewObCHb+bBaE12Ra19PHJ3unH4VD4ubSso39dtGVDuN0BANQhp3NOx/ LqBd2QjCdbPpW87H+hyzDib9gAVDzDpDY+jg4J9zrP998hLOXRR410a6fYpm9KtrAtnL z2uYgmGB57LzsbhfcQb8fk6bE2W0C3YhlPBirC60tFZ5P3LD6S6cvKb2TAraZ1j8JNIG 4ELw== X-Received: by 10.112.34.6 with SMTP id v6mr2947894lbi.21.1376196002502; Sat, 10 Aug 2013 21:40:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.162.162 with HTTP; Sat, 10 Aug 2013 21:39:22 -0700 (PDT) In-Reply-To: References: <8B53C542-5CC3-45E6-AA62-B9F52A735EE5@my.gd> From: saeedeh motlagh Date: Sun, 11 Aug 2013 09:09:22 +0430 Message-ID: Subject: Re: how calculate the number of ip addresses in a range? To: Damien Fleuriot Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Kimmo Paasiala , s m , Peter Wemm , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Aug 2013 04:40:05 -0000 thank you all guys for your answers. Peter, of course it's not my homework!!!!!! in fact, i have a program which manages dhcp. i want to limit the number of ip address which can be assigned by dhcp server. in order to do that, i should know how many ip addresses are available in the range that is defined for server and if the number of available ip addresses are greater than valid threshold, it's error. so as you said, i should know the math for calculate this number. thank you again guys for your answers but they do not solve my problem. any body knows what is the formula to calculate the valid ip addresses for any desired ranges? Thanks On Sat, Aug 10, 2013 at 5:19 AM, Damien Fleuriot wrote: > > > On 10 Aug 2013, at 01:07, Kimmo Paasiala wrote: > > > On Sat, Aug 10, 2013 at 1:44 AM, Peter Wemm wrote: > >> On Fri, Aug 9, 2013 at 9:34 AM, Fleuriot Damien wrote: > >>> > >>> On Aug 8, 2013, at 10:27 AM, Peter Wemm wrote: > >>> > >>>> On Thu, Aug 8, 2013 at 12:04 AM, s m wrote: > >>>>> hello guys, > >>>>> > >>>>> i have a question about ip addresses. i know my question is not > related to > >>>>> freebsd but i googled a lot and found nothing useful and don't know > where i > >>>>> should ask my question. > >>>>> > >>>>> i want to know how can i calculate the number of ip addresses in a > range? > >>>>> for example if i have 192.0.0.1 192.100.255.254 with mask 8, how > many ip > >>>>> addresses are available in this range? is there any formula to > calculate > >>>>> the number of ip addresses for any range? > >>>>> > >>>>> i'm confusing about it. please help me to clear my mind. > >>>>> thanks in advance, > >>>> > >>>> My immediate reaction is.. is this a homework / classwork / > assignment? > >>>> > >>>> Anyway, you can think of it by converting your start and end addresses > >>>> to an integer. Over simplified: > >>>> > >>>> $ cat homework.c > >>>> main() > >>>> { > >>>> int start = (192 << 24) | (0 << 16) | (0 << 8) | 1; > >>>> int end = (192 << 24) | (100 << 16) | (255 << 8) | 254; > >>>> printf("start %d end %d range %d\n", start, end, (end - start) + 1); > >>>> } > >>>> $ ./homework > >>>> start -1073741823 end -1067122690 range 6619134 > >>>> > >>>> The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two > >>>> usable addresses. > >>>> > >>>> I'm not sure what you want to do with the mask of 8. > >>>> > >>>> You can also do it with ntohl(inet_addr("address")) as well and a > >>>> multitude of other ways. > >>> > >>> > >>> Hold on a second, why would you correct the base zero ? > >>> It can be a valid IP address. > >> > >> There is one usable address in a range of 10.0.0.1 - 10.0.0.1. > >> Converting to an integer and subtracting would be zero. Hence +1. > >> > >> -- > > > > To elaborate on this, for every subnet regardless of the address/mask > > combination there are two unusable addresses: The first address aka > > the "network address" and the last address aka the "broadcast > > address". There may be usable address in between the two that end in > > one of more zeros but those addresses are still valid. Some operating > > systems got this horribly wrong and marked any address ending with a > > single zero as invalid, windows 2000 was one of them. > > > > -Kimmo > > > Kimmo, > > That is untrue regarding /31 netmasks where you theoretically have 2^1 -2 > addresses. > > With such a short netmask the only 2 addresses are usable. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- *Sa.M* From owner-freebsd-net@FreeBSD.ORG Sun Aug 11 07:30:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BB1B2DB1 for ; Sun, 11 Aug 2013 07:30:06 +0000 (UTC) (envelope-from darrenr@netbsd.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8C36C2753 for ; Sun, 11 Aug 2013 07:30:06 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id EF0CF21042; Sun, 11 Aug 2013 03:30:04 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 11 Aug 2013 03:30:04 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=D6KE2y6BRMNQxAUzwu58/N E6YdM=; b=Qfe6BQp1KhpdIenmT298tBJNAuVzgRhxxnf0TTQhs+Ph0y49S3Vncw knq3v2bZz523jhsQUpV8MC9ZqE/kJ24lzkqpUllwvWPI0DceLrJQqMObi3d1PmRM 3DOSPqHl9fK6VSRFqtyT4wgBMJl9Q9MaXbtUjPUIl6Uu0D8iuVcLY= X-Sasl-enc: LFRxrr2wrd8TwRIpLMVSYYFBl5DPCcbaFKeHmZfUqdlR 1376206204 Received: from [172.20.10.2] (unknown [101.172.151.26]) by mail.messagingengine.com (Postfix) with ESMTPA id 64810C00E7F; Sun, 11 Aug 2013 03:30:03 -0400 (EDT) Message-ID: <52073E3D.8060008@netbsd.org> Date: Sun, 11 Aug 2013 17:33:17 +1000 From: Darren Reed Organization: NetBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Matt Thomas Subject: Re: BPF_MISC+BPF_COP and BPF_COPX References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> <38CDC9BB-09C7-4241-8746-163BD15B80EC@cs.columbia.edu> <20130809203446.428A714A308@mail.netbsd.org> <20130809204436.GA3261@panix.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tech-net@NetBSD.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: darrenr@netbsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 07:30:06 -0000 On 10/08/2013 7:23 AM, Matt Thomas wrote: > ... > The possibility of the COP/COPX functions doing bad things is over wrought. It makes the assumption of avoiding BPF and then coding everything is safer than using BPF and COP/COPX functions. Depends on what you mean by "bad things." Thus far I haven't seen a proper problem statement, only this: > The problem is simple: I want a generic mechanism to offload more complex > packet inspection operations, e.g. lookup IP address in some container or > walk IPv6 headers and return some offsets. IMHO, the IPv6 problem is and will be common enough to deserve its own instructionas happened with IPv4 and determining the offset of the first byte after the IPv4 header. But the generic offload problem hasn't been explained nearly enough. Is it required for NPF? Is it required for tcpdump? Is it required for dhcpd? ... I don't think we know nearly enough about what the problem is in order to be able to judge whether or not the solution is acceptable. Darren From owner-freebsd-net@FreeBSD.ORG Sun Aug 11 10:31:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3AB65AEE for ; Sun, 11 Aug 2013 10:31:02 +0000 (UTC) (envelope-from sam.gh1986@gmail.com) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9876B2E45 for ; Sun, 11 Aug 2013 10:31:01 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id t13so4106055lbd.2 for ; Sun, 11 Aug 2013 03:30:59 -0700 (PDT) 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=DwGmkly6PtQD2MAtWx7jxI948oZDP4W0hWfO8jDWbEQ=; b=xlAiC6vxEGy/Ga/E3zpFxV6yRv186Zo9PLznCTtEkhXYO6ev6PRwhTJDlMnA9hBLtf Dy0THZdQV5QmHSA2QvaaT7dS/VwDN8ItmhnYpHlWhDkA4UVgLh8GsEmwzkJcoa1XEUzI TIl5wbVQwSBeKusISmvyL2x87EFKN+ygKcbGpvbJnlMbg87E+S3rf2q+Wqg2ey03YCI6 MkhUM7m6SBn3kFkorHf0S9Bmz8YwaJDe1Ss48TyYD31WkBCfcmtDvbk78xsmJsCBVWfm jCaF7FPbgXCqp5fJc+8Az8beTE5PrIbdeU9TzvYv1TXFHm+ft/l8eByA4Z/7fLt+/nZA iwfg== MIME-Version: 1.0 X-Received: by 10.152.22.198 with SMTP id g6mr3502000laf.5.1376217059467; Sun, 11 Aug 2013 03:30:59 -0700 (PDT) Received: by 10.112.147.230 with HTTP; Sun, 11 Aug 2013 03:30:59 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Aug 2013 15:00:59 +0430 Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: s m To: Andreas Nilsson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Olivier Nicole , FreeBSD Net , Olivier Nicole X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Aug 2013 10:31:02 -0000 hello again guys after understanding why dhcp server core dumps with a wide range (it causes out of memory), if i limit my range it's ok. but some times user define a wide range for example some million available ip addresses while there is just some hundred client in the network. in this situation, dhcp server use a lot of ram memory which is not good at all. how dhcp server acts? why does it need a lot memory? is there any patch to optimize it? if not, is there any other any ports in freebsd to use instead and have better performance? thanks in advance SAM On Wed, Aug 7, 2013 at 11:07 AM, s m wrote: > yes, i solved my problem. > thanks every body for your answers. it help me a lot. > SAM > > > On Tue, Aug 6, 2013 at 2:08 PM, Andreas Nilsson wrote: > >> >> >> >> On Tue, Aug 6, 2013 at 11:29 AM, s m wrote: >> >>> thanks Andreas, that's it!!! >>> you know i have user interface program for dhcp. users don't know how >>> dhcp works and just enter desired range in text box. i should handle all >>> entered ranges. in order to do that, i should know how dhcp works with all >>> different ranges and return errors if some ranges is not equivalent like >>> the sample one. >>> >> >> Ok. Someone more versed in debugging should probably determine if the >> crash is in libc or just that dhcp does not handle malloc error. >> >> >>> >>> so. if i want to have network with mask 8, i should limit my range, >>> right? have you any suggestion what is the maximum range for netmask 8? >>> thanks for your reply again. it clears my mind:) >>> >> >> Exactly. >> >> I just tried >> 192.0.0.1-192.220.255.255 which works ( takes ~3 minutes to start, using >> 4.5gb of ram ) >> and then >> 192.0.0.1-192.221.255.255 which segfaults. >> >> The machine I test on does have 16gb of ram and 16gb of swap, so there >> should be a lot more mem available. >> >> Best regards >> Andreas >> >>> >>> >>> On Tue, Aug 6, 2013 at 1:35 PM, Andreas Nilsson wrote: >>> >>>> >>>> >>>> >>>> On Tue, Aug 6, 2013 at 10:59 AM, Andreas Nilsson wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Aug 6, 2013 at 10:40 AM, Olivier Nicole < >>>>> olivier.nicole@cs.ait.ac.th> wrote: >>>>> >>>>>> Sam, >>>>>> >>>>>> > my problem is to know how define a network with mask 8 and dhcp >>>>>> server >>>>>> > works correctly with it! you know if i config my dhcpd.conf like >>>>>> below, i >>>>>> > have core dump either: >>>>>> > subnet 10.0.0.0 netmask 255.0.0.0 >>>>>> > { >>>>>> > range 10.0.0.1 10.255.255.254; >>>>>> > } >>>>>> > >>>>>> > do you know how should i define my range ?? >>>>>> >>>>>> The reason may be that 2^24 machines in a subnet is such a non-sense >>>>>> that dhcp simply cannot manage it. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Olivier >>>>>> >>>>>> > >>>>>> > On Tue, Aug 6, 2013 at 12:23 PM, Olivier Nicole < >>>>>> Olivier.Nicole@cs.ait.ac.th >>>>>> >> wrote: >>>>>> > >>>>>> >> Sam, >>>>>> >> >>>>>> >> > subnet 192.0.0.0 netmask 255.0.0.0 >>>>>> >> >>>>>> >> I know it is not the answer to your question, but you are wrong in >>>>>> your >>>>>> >> guess that 192.0.0.0/8 is all private IPs. Only 192.168.0.0/16 is. >>>>>> >> >>>>>> >> I know that for certain because my own IP starts with 192. >>>>>> >> >>>>>> >> If you want a full /8 private, you can only use 10.0.0.0/8 >>>>>> >> >>>>>> >> Bets regards, >>>>>> >> >>>>>> >> Olivier >>>>>> >> >>>>>> >> -- >>>>>> >> >>>>>> >>>>>> >>>>> Well, I would guess it may run out of memory... I did a few tests: >>>>> 192.0.0.0 - 192.128.255.255 does work ( using ~2.5Gb RAM ). >>>>> 192.0.0.0 - 192.192.255.255 does work ( using ~4Gb RAM ). >>>>> 192.0.0.0 - 192.200.255.255 does work ( using ~4.2Gb RAM ). >>>>> 192.0.0.0 - 192.224.255.255 dumps core >>>>> >>>>> Why would you want to have such a huge range? >>>>> >>>>> Best regards >>>>> Andreas >>>>> >>>> >>>> Also, a quick look at the core file gives same indications: >>>> #0 0x0000000800c67a21 in _malloc_prefork () from /lib/libc.so.7 >>>> #1 0x0000000800c6b72a in malloc () from /lib/libc.so.7 >>>> #2 0x000000000047b43b in omapi_object_dereference () >>>> #3 0x00000000004844db in do_ip4_hash () >>>> #4 0x0000000000484571 in do_ip4_hash () >>>> #5 0x0000000000438a45 in pool_timer () >>>> #6 0x000000000041dcd7 in trace_conf_stop () >>>> #7 0x000000000041fc4e in trace_conf_stop () >>>> #8 0x0000000000420698 in trace_conf_stop () >>>> #9 0x0000000000420ecc in trace_conf_stop () >>>> #10 0x0000000000420197 in trace_conf_stop () >>>> #11 0x00000000004247f3 in trace_conf_stop () >>>> #12 0x000000000041f210 in trace_conf_stop () >>>> #13 0x000000000040f3bf in lease_pinged () >>>> #14 0x000000000040d451 in ?? () >>>> #15 0x00000008007d7000 in ?? () >>>> #16 0x0000000000000000 in ?? () >>>> >>>> Best regards >>>> Andreas >>>> >>>> >>> >> > From owner-freebsd-net@FreeBSD.ORG Sun Aug 11 10:48:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BF4609B for ; Sun, 11 Aug 2013 10:48:06 +0000 (UTC) (envelope-from olivier2553@gmail.com) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7BBED2EDD for ; Sun, 11 Aug 2013 10:48:06 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id o19so560447qap.20 for ; Sun, 11 Aug 2013 03:48:05 -0700 (PDT) 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=zIT1I25GG2WJLoy1PV5OSg+J9Qew+kVIeAd/ueyrb2A=; b=dO3qZ0APXIPiG3j23eO2lMud1302P2DsZtJ/Ub928XO94ZDJ2DG2g5D0QYdY+IQngq o+MqSCjXIth3rM2fYM1J2Ky4u0wdEQN0MUfGV4s4B5/Cez4XvyZH2mHXG7VKBCQ54gIt kqPe33awd0XRfzISa46JrX10XF9AGs1L+vJKXeKPW826/6vSH++YcRVHaFtERNl8RCZk 6BTp58Y/MkpmyUvFUFq0MaqfxiWzEdGP9f/IHxCO8Iw7qNr5W0DJMM6po/hA1VtuoTSb MtII/Ly3Lv9xrkba4vGjfOcV6nZeMjGubBCsg20WapMaSjNrNlawMQCGED7btjSEjGrL 7ilw== MIME-Version: 1.0 X-Received: by 10.224.88.70 with SMTP id z6mr14788426qal.31.1376218085522; Sun, 11 Aug 2013 03:48:05 -0700 (PDT) Sender: olivier2553@gmail.com Received: by 10.49.62.41 with HTTP; Sun, 11 Aug 2013 03:48:05 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Aug 2013 17:48:05 +0700 X-Google-Sender-Auth: 7DUtbwPwcUzoOTheWG_NMPqvpWE Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: Olivier Nicole To: s m Content-Type: text/plain; charset=ISO-8859-1 Cc: Olivier Nicole , FreeBSD Net , Andreas Nilsson X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Aug 2013 10:48:06 -0000 Sam, > after understanding why dhcp server core dumps with a wide range (it causes > out of memory), if i limit my range it's ok. but some times user define a > wide range for example some million available ip addresses while there is > just some hundred client in the network. in this situation, dhcp server use > a lot of ram memory which is not good at all. how dhcp server acts? why does > it need a lot memory? is there any patch to optimize it? if not, is there > any other any ports in freebsd to use instead and have better performance? In the real life, it's very uncommon that you give millions of IP addresses to a customer when he really needs only hundreds. If only because you will usually charge your customers by the number of devices on the network and most customers try to not pay in excess for a service they will not use. Installing and running a DHCP server is for people who know what they are doing, because it has strong implications on the way the network is running, so users who install DHCP are supposed to know what they are doing. It is also possible to have a centralized DHCP server that you control, and each subnet of each customer make use of your centralized DHCP. You can propose ways for your customers to upgrade the range for their own subnet, but you are controlling the script they use and you can install limitations. It's really useless to loose time finding some patches that would get DHCP run for million of addresses, in real life, a network is never a /8 but rather a /22 or less, it makes the thing manageable. Eventually, consider that a /8 subnet cannot be NATed, as a NAT can only manage 2^16 connections at a given time. Best regards, Olivier > > thanks in advance > SAM > > > On Wed, Aug 7, 2013 at 11:07 AM, s m wrote: >> >> yes, i solved my problem. >> thanks every body for your answers. it help me a lot. >> SAM >> >> >> On Tue, Aug 6, 2013 at 2:08 PM, Andreas Nilsson >> wrote: >>> >>> >>> >>> >>> On Tue, Aug 6, 2013 at 11:29 AM, s m wrote: >>>> >>>> thanks Andreas, that's it!!! >>>> you know i have user interface program for dhcp. users don't know how >>>> dhcp works and just enter desired range in text box. i should handle all >>>> entered ranges. in order to do that, i should know how dhcp works with all >>>> different ranges and return errors if some ranges is not equivalent like the >>>> sample one. >>> >>> >>> Ok. Someone more versed in debugging should probably determine if the >>> crash is in libc or just that dhcp does not handle malloc error. >>> >>>> >>>> >>>> so. if i want to have network with mask 8, i should limit my range, >>>> right? have you any suggestion what is the maximum range for netmask 8? >>>> thanks for your reply again. it clears my mind:) >>> >>> >>> Exactly. >>> >>> I just tried >>> 192.0.0.1-192.220.255.255 which works ( takes ~3 minutes to start, using >>> 4.5gb of ram ) >>> and then >>> 192.0.0.1-192.221.255.255 which segfaults. >>> >>> The machine I test on does have 16gb of ram and 16gb of swap, so there >>> should be a lot more mem available. >>> >>> Best regards >>> Andreas >>>> >>>> >>>> >>>> On Tue, Aug 6, 2013 at 1:35 PM, Andreas Nilsson >>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Aug 6, 2013 at 10:59 AM, Andreas Nilsson >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 6, 2013 at 10:40 AM, Olivier Nicole >>>>>> wrote: >>>>>>> >>>>>>> Sam, >>>>>>> >>>>>>> > my problem is to know how define a network with mask 8 and dhcp >>>>>>> > server >>>>>>> > works correctly with it! you know if i config my dhcpd.conf like >>>>>>> > below, i >>>>>>> > have core dump either: >>>>>>> > subnet 10.0.0.0 netmask 255.0.0.0 >>>>>>> > { >>>>>>> > range 10.0.0.1 10.255.255.254; >>>>>>> > } >>>>>>> > >>>>>>> > do you know how should i define my range ?? >>>>>>> >>>>>>> The reason may be that 2^24 machines in a subnet is such a non-sense >>>>>>> that dhcp simply cannot manage it. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Olivier >>>>>>> >>>>>>> > >>>>>>> > On Tue, Aug 6, 2013 at 12:23 PM, Olivier Nicole >>>>>>> > >>>>>> >> wrote: >>>>>>> > >>>>>>> >> Sam, >>>>>>> >> >>>>>>> >> > subnet 192.0.0.0 netmask 255.0.0.0 >>>>>>> >> >>>>>>> >> I know it is not the answer to your question, but you are wrong in >>>>>>> >> your >>>>>>> >> guess that 192.0.0.0/8 is all private IPs. Only 192.168.0.0/16 is. >>>>>>> >> >>>>>>> >> I know that for certain because my own IP starts with 192. >>>>>>> >> >>>>>>> >> If you want a full /8 private, you can only use 10.0.0.0/8 >>>>>>> >> >>>>>>> >> Bets regards, >>>>>>> >> >>>>>>> >> Olivier >>>>>>> >> >>>>>>> >> -- >>>>>>> >> >>>>>>> >>>>>> >>>>>> Well, I would guess it may run out of memory... I did a few tests: >>>>>> 192.0.0.0 - 192.128.255.255 does work ( using ~2.5Gb RAM ). >>>>>> 192.0.0.0 - 192.192.255.255 does work ( using ~4Gb RAM ). >>>>>> 192.0.0.0 - 192.200.255.255 does work ( using ~4.2Gb RAM ). >>>>>> 192.0.0.0 - 192.224.255.255 dumps core >>>>>> >>>>>> Why would you want to have such a huge range? >>>>>> >>>>>> Best regards >>>>>> Andreas >>>>> >>>>> >>>>> Also, a quick look at the core file gives same indications: >>>>> #0 0x0000000800c67a21 in _malloc_prefork () from /lib/libc.so.7 >>>>> #1 0x0000000800c6b72a in malloc () from /lib/libc.so.7 >>>>> #2 0x000000000047b43b in omapi_object_dereference () >>>>> #3 0x00000000004844db in do_ip4_hash () >>>>> #4 0x0000000000484571 in do_ip4_hash () >>>>> #5 0x0000000000438a45 in pool_timer () >>>>> #6 0x000000000041dcd7 in trace_conf_stop () >>>>> #7 0x000000000041fc4e in trace_conf_stop () >>>>> #8 0x0000000000420698 in trace_conf_stop () >>>>> #9 0x0000000000420ecc in trace_conf_stop () >>>>> #10 0x0000000000420197 in trace_conf_stop () >>>>> #11 0x00000000004247f3 in trace_conf_stop () >>>>> #12 0x000000000041f210 in trace_conf_stop () >>>>> #13 0x000000000040f3bf in lease_pinged () >>>>> #14 0x000000000040d451 in ?? () >>>>> #15 0x00000008007d7000 in ?? () >>>>> #16 0x0000000000000000 in ?? () >>>>> >>>>> Best regards >>>>> Andreas >>>>> >>>> >>> >> > From owner-freebsd-net@FreeBSD.ORG Sun Aug 11 13:41:03 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22C52DE9; Sun, 11 Aug 2013 13:41:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC08725FB; Sun, 11 Aug 2013 13:41:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7BDf2FJ013211; Sun, 11 Aug 2013 13:41:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7BDf2r6013210; Sun, 11 Aug 2013 13:41:02 GMT (envelope-from linimon) Date: Sun, 11 Aug 2013 13:41:02 GMT Message-Id: <201308111341.r7BDf2r6013210@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/181225: [infiniband] [patch] unloading ipoib crashes the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Aug 2013 13:41:03 -0000 Old Synopsis: unloading ipoib crashes the kernel New Synopsis: [infiniband] [patch] unloading ipoib crashes the kernel Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Aug 11 13:40:22 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=181225 From owner-freebsd-net@FreeBSD.ORG Sun Aug 11 19:30:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5A39AA17 for ; Sun, 11 Aug 2013 19:30:32 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D03592415 for ; Sun, 11 Aug 2013 19:30:31 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id x55so4851368wes.18 for ; Sun, 11 Aug 2013 12:30:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=OOWzzlgofC2+Up1cf7y/yLWvW80lcVxAkC2QN+cbw1Q=; b=BbvEFo1+VffBr4c+JcCfWL13oDsdXcMxWShQvMTkLfskUpmWLU9YsfD8zSvE2gFDgD Opu0Dyo0cI1/4tRDhFUUNHbuqylHLm0YWNrKr+p+W7V4gkJnwuIw9JhsW5piDAPFTWs1 NFEaRAp7qyGc0wfT5XC2HTA46NejjYePLZiobWS4dvvUJaY3E9KyR878AcbTGAVneDLX vraEykpN3VifnGi3GWI+vydk488rzL8h5ZTh6/nlEmlry3MIEQ2rknL5JAnq9tYM0hAo ivxCYvcsPtoqT84zcma+p/AWjFzeiGgmaca7qHfChezAqmz5WBwVN/G80HXDPwVCZOSz Z+bw== X-Gm-Message-State: ALoCoQlO4+OVLb5vW2nzakx6fGHyIabIgLep36ZyxNhOH4aEVMJPE3n6yp+13CsgXQGjSpHef/oj X-Received: by 10.194.201.202 with SMTP id kc10mr10968208wjc.1.1376248941167; Sun, 11 Aug 2013 12:22:21 -0700 (PDT) Received: from [10.51.222.45] (86.20.90.92.rev.sfr.net. [92.90.20.86]) by mx.google.com with ESMTPSA id jf9sm12667338wic.5.2013.08.11.12.22.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 11 Aug 2013 12:22:20 -0700 (PDT) References: <8B53C542-5CC3-45E6-AA62-B9F52A735EE5@my.gd> Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: X-Mailer: iPhone Mail (10B144) From: Damien Fleuriot Subject: Re: how calculate the number of ip addresses in a range? Date: Sun, 11 Aug 2013 21:20:40 +0200 To: saeedeh motlagh Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Kimmo Paasiala , s m , Peter Wemm , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Aug 2013 19:30:32 -0000 Yup. Your available addresses are: (2 ^ (32 - netmask) ) - 2 Example for a 29: 2^3 - 2 Example for a /28: 2^4 - 2 On 11 Aug 2013, at 06:39, saeedeh motlagh wrote:= > thank you all guys for your answers. > Peter, of course it's not my homework!!!!!! in fact, i have a program whic= h manages dhcp. i want to limit the number of ip address which can be assign= ed by dhcp server. in order to do that, i should know how many ip addresses a= re available in the range that is defined for server and if the number of av= ailable ip addresses are greater than valid threshold, it's error. so as you= said, i should know the math for calculate this number. >=20 > thank you again guys for your answers but they do not solve my problem. an= y body knows what is the formula to calculate the valid ip addresses for any= desired ranges? > Thanks=20 >=20 >=20 > On Sat, Aug 10, 2013 at 5:19 AM, Damien Fleuriot wrote: >>=20 >>=20 >> On 10 Aug 2013, at 01:07, Kimmo Paasiala wrote: >>=20 >> > On Sat, Aug 10, 2013 at 1:44 AM, Peter Wemm wrote: >> >> On Fri, Aug 9, 2013 at 9:34 AM, Fleuriot Damien wrote: >> >>> >> >>> On Aug 8, 2013, at 10:27 AM, Peter Wemm wrote: >> >>> >> >>>> On Thu, Aug 8, 2013 at 12:04 AM, s m wrote: >> >>>>> hello guys, >> >>>>> >> >>>>> i have a question about ip addresses. i know my question is not rel= ated to >> >>>>> freebsd but i googled a lot and found nothing useful and don't know= where i >> >>>>> should ask my question. >> >>>>> >> >>>>> i want to know how can i calculate the number of ip addresses in a r= ange? >> >>>>> for example if i have 192.0.0.1 192.100.255.254 with mask 8, how ma= ny ip >> >>>>> addresses are available in this range? is there any formula to calc= ulate >> >>>>> the number of ip addresses for any range? >> >>>>> >> >>>>> i'm confusing about it. please help me to clear my mind. >> >>>>> thanks in advance, >> >>>> >> >>>> My immediate reaction is.. is this a homework / classwork / assignme= nt? >> >>>> >> >>>> Anyway, you can think of it by converting your start and end address= es >> >>>> to an integer. Over simplified: >> >>>> >> >>>> $ cat homework.c >> >>>> main() >> >>>> { >> >>>> int start =3D (192 << 24) | (0 << 16) | (0 << 8) | 1; >> >>>> int end =3D (192 << 24) | (100 << 16) | (255 << 8) | 254; >> >>>> printf("start %d end %d range %d\n", start, end, (end - start) + 1);= >> >>>> } >> >>>> $ ./homework >> >>>> start -1073741823 end -1067122690 range 6619134 >> >>>> >> >>>> The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two >> >>>> usable addresses. >> >>>> >> >>>> I'm not sure what you want to do with the mask of 8. >> >>>> >> >>>> You can also do it with ntohl(inet_addr("address")) as well and a >> >>>> multitude of other ways. >> >>> >> >>> >> >>> Hold on a second, why would you correct the base zero ? >> >>> It can be a valid IP address. >> >> >> >> There is one usable address in a range of 10.0.0.1 - 10.0.0.1. >> >> Converting to an integer and subtracting would be zero. Hence +1. >> >> >> >> -- >> > >> > To elaborate on this, for every subnet regardless of the address/mask >> > combination there are two unusable addresses: The first address aka >> > the "network address" and the last address aka the "broadcast >> > address". There may be usable address in between the two that end in >> > one of more zeros but those addresses are still valid. Some operating >> > systems got this horribly wrong and marked any address ending with a >> > single zero as invalid, windows 2000 was one of them. >> > >> > -Kimmo >>=20 >>=20 >> Kimmo, >>=20 >> That is untrue regarding /31 netmasks where you theoretically have 2^1 -2= addresses. >>=20 >> With such a short netmask the only 2 addresses are usable. >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 >=20 >=20 > --=20 > Sa.M From owner-freebsd-net@FreeBSD.ORG Mon Aug 12 04:42:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5AC52AC2 for ; Mon, 12 Aug 2013 04:42:55 +0000 (UTC) (envelope-from sam.gh1986@gmail.com) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B71D2291E for ; Mon, 12 Aug 2013 04:42:54 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id w10so4388087lbi.7 for ; Sun, 11 Aug 2013 21:42:52 -0700 (PDT) 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=6oG13CT+LwXEGS4AkXgQrzcZrFA0n4Tec8bU/TYm1a0=; b=p78pJhBDlnMakcqD6f6P6jRCWyw/xHCRQaSJfuP68neVxL2/1XhqB753NJlYRg4w+F aV8O7GS8waJBgeoPrG6P+QbJjukwBVfc4opirx+no66WoFXeW7LWucOXkrbCxIO92E+u bDAmQo6sWcbE/CjtSLBxN7Wmxh8cf04o/1bA1tghc01v2wQAMwHvYFaUoeIwMg+rc8sk tTAaO3W1Bcb+ZfMByDHuLhQQh3yQ385iAehUgrZHegMtix394maYgM8Y/0rwTX1NYRsc uRh6Jk+iK0hkOxQeVkz8TdXe2uuSWqKQJfAFftAaKNQyTr1c2m51CKjZGt2jXDMv/drZ ZkWw== MIME-Version: 1.0 X-Received: by 10.112.33.146 with SMTP id r18mr8911813lbi.48.1376282572657; Sun, 11 Aug 2013 21:42:52 -0700 (PDT) Received: by 10.112.147.230 with HTTP; Sun, 11 Aug 2013 21:42:52 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Aug 2013 09:12:52 +0430 Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: s m To: Olivier Nicole Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Olivier Nicole , FreeBSD Net , Andreas Nilsson X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Aug 2013 04:42:55 -0000 you're right Olivier, but you know i have a user interface for dhcp and i should handle all the network and ranges which are inserted by user and logically are true. network with mask 8, logically is true and having million available ip address, too. i just wanna know if there is any solution to improve my performance or not. thanks On Sun, Aug 11, 2013 at 3:18 PM, Olivier Nicole wrote: > Sam, > > > after understanding why dhcp server core dumps with a wide range (it > causes > > out of memory), if i limit my range it's ok. but some times user define a > > wide range for example some million available ip addresses while there is > > just some hundred client in the network. in this situation, dhcp server > use > > a lot of ram memory which is not good at all. how dhcp server acts? why > does > > it need a lot memory? is there any patch to optimize it? if not, is there > > any other any ports in freebsd to use instead and have better > performance? > > In the real life, it's very uncommon that you give millions of IP > addresses to a customer when he really needs only hundreds. If only > because you will usually charge your customers by the number of > devices on the network and most customers try to not pay in excess for > a service they will not use. > > Installing and running a DHCP server is for people who know what they > are doing, because it has strong implications on the way the network > is running, so users who install DHCP are supposed to know what they > are doing. > > It is also possible to have a centralized DHCP server that you > control, and each subnet of each customer make use of your centralized > DHCP. You can propose ways for your customers to upgrade the range for > their own subnet, but you are controlling the script they use and you > can install limitations. > > It's really useless to loose time finding some patches that would get > DHCP run for million of addresses, in real life, a network is never a > /8 but rather a /22 or less, it makes the thing manageable. > > Eventually, consider that a /8 subnet cannot be NATed, as a NAT can > only manage 2^16 connections at a given time. > > Best regards, > > Olivier > > > > > thanks in advance > > SAM > > > > > > On Wed, Aug 7, 2013 at 11:07 AM, s m wrote: > >> > >> yes, i solved my problem. > >> thanks every body for your answers. it help me a lot. > >> SAM > >> > >> > >> On Tue, Aug 6, 2013 at 2:08 PM, Andreas Nilsson > >> wrote: > >>> > >>> > >>> > >>> > >>> On Tue, Aug 6, 2013 at 11:29 AM, s m wrote: > >>>> > >>>> thanks Andreas, that's it!!! > >>>> you know i have user interface program for dhcp. users don't know how > >>>> dhcp works and just enter desired range in text box. i should handle > all > >>>> entered ranges. in order to do that, i should know how dhcp works > with all > >>>> different ranges and return errors if some ranges is not equivalent > like the > >>>> sample one. > >>> > >>> > >>> Ok. Someone more versed in debugging should probably determine if the > >>> crash is in libc or just that dhcp does not handle malloc error. > >>> > >>>> > >>>> > >>>> so. if i want to have network with mask 8, i should limit my range, > >>>> right? have you any suggestion what is the maximum range for netmask > 8? > >>>> thanks for your reply again. it clears my mind:) > >>> > >>> > >>> Exactly. > >>> > >>> I just tried > >>> 192.0.0.1-192.220.255.255 which works ( takes ~3 minutes to start, > using > >>> 4.5gb of ram ) > >>> and then > >>> 192.0.0.1-192.221.255.255 which segfaults. > >>> > >>> The machine I test on does have 16gb of ram and 16gb of swap, so there > >>> should be a lot more mem available. > >>> > >>> Best regards > >>> Andreas > >>>> > >>>> > >>>> > >>>> On Tue, Aug 6, 2013 at 1:35 PM, Andreas Nilsson > >>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Tue, Aug 6, 2013 at 10:59 AM, Andreas Nilsson > > >>>>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Tue, Aug 6, 2013 at 10:40 AM, Olivier Nicole > >>>>>> wrote: > >>>>>>> > >>>>>>> Sam, > >>>>>>> > >>>>>>> > my problem is to know how define a network with mask 8 and dhcp > >>>>>>> > server > >>>>>>> > works correctly with it! you know if i config my dhcpd.conf like > >>>>>>> > below, i > >>>>>>> > have core dump either: > >>>>>>> > subnet 10.0.0.0 netmask 255.0.0.0 > >>>>>>> > { > >>>>>>> > range 10.0.0.1 10.255.255.254; > >>>>>>> > } > >>>>>>> > > >>>>>>> > do you know how should i define my range ?? > >>>>>>> > >>>>>>> The reason may be that 2^24 machines in a subnet is such a > non-sense > >>>>>>> that dhcp simply cannot manage it. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> > >>>>>>> Olivier > >>>>>>> > >>>>>>> > > >>>>>>> > On Tue, Aug 6, 2013 at 12:23 PM, Olivier Nicole > >>>>>>> > >>>>>>> >> wrote: > >>>>>>> > > >>>>>>> >> Sam, > >>>>>>> >> > >>>>>>> >> > subnet 192.0.0.0 netmask 255.0.0.0 > >>>>>>> >> > >>>>>>> >> I know it is not the answer to your question, but you are wrong > in > >>>>>>> >> your > >>>>>>> >> guess that 192.0.0.0/8 is all private IPs. Only 192.168.0.0/16is. > >>>>>>> >> > >>>>>>> >> I know that for certain because my own IP starts with 192. > >>>>>>> >> > >>>>>>> >> If you want a full /8 private, you can only use 10.0.0.0/8 > >>>>>>> >> > >>>>>>> >> Bets regards, > >>>>>>> >> > >>>>>>> >> Olivier > >>>>>>> >> > >>>>>>> >> -- > >>>>>>> >> > >>>>>>> > >>>>>> > >>>>>> Well, I would guess it may run out of memory... I did a few tests: > >>>>>> 192.0.0.0 - 192.128.255.255 does work ( using ~2.5Gb RAM ). > >>>>>> 192.0.0.0 - 192.192.255.255 does work ( using ~4Gb RAM ). > >>>>>> 192.0.0.0 - 192.200.255.255 does work ( using ~4.2Gb RAM ). > >>>>>> 192.0.0.0 - 192.224.255.255 dumps core > >>>>>> > >>>>>> Why would you want to have such a huge range? > >>>>>> > >>>>>> Best regards > >>>>>> Andreas > >>>>> > >>>>> > >>>>> Also, a quick look at the core file gives same indications: > >>>>> #0 0x0000000800c67a21 in _malloc_prefork () from /lib/libc.so.7 > >>>>> #1 0x0000000800c6b72a in malloc () from /lib/libc.so.7 > >>>>> #2 0x000000000047b43b in omapi_object_dereference () > >>>>> #3 0x00000000004844db in do_ip4_hash () > >>>>> #4 0x0000000000484571 in do_ip4_hash () > >>>>> #5 0x0000000000438a45 in pool_timer () > >>>>> #6 0x000000000041dcd7 in trace_conf_stop () > >>>>> #7 0x000000000041fc4e in trace_conf_stop () > >>>>> #8 0x0000000000420698 in trace_conf_stop () > >>>>> #9 0x0000000000420ecc in trace_conf_stop () > >>>>> #10 0x0000000000420197 in trace_conf_stop () > >>>>> #11 0x00000000004247f3 in trace_conf_stop () > >>>>> #12 0x000000000041f210 in trace_conf_stop () > >>>>> #13 0x000000000040f3bf in lease_pinged () > >>>>> #14 0x000000000040d451 in ?? () > >>>>> #15 0x00000008007d7000 in ?? () > >>>>> #16 0x0000000000000000 in ?? () > >>>>> > >>>>> Best regards > >>>>> Andreas > >>>>> > >>>> > >>> > >> > > > From owner-freebsd-net@FreeBSD.ORG Mon Aug 12 05:19:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 32184DD1 for ; Mon, 12 Aug 2013 05:19:47 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 75B852A47 for ; Mon, 12 Aug 2013 05:19:45 +0000 (UTC) Received: (qmail 27743 invoked from network); 12 Aug 2013 05:13:03 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 12 Aug 2013 05:13:03 -0000 Date: Mon, 12 Aug 2013 07:13:03 +0200 (CEST) Message-Id: <20130812.071303.74723582.sthaug@nethelp.no> To: sam.gh1986@gmail.com Subject: Re: how define network with mask 8 for dhcp server? From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: on@cs.ait.ac.th, freebsd-net@freebsd.org, olivier.nicole@cs.ait.ac.th, andrnils@gmail.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Aug 2013 05:19:47 -0000 > you're right Olivier, but you know i have a user interface for dhcp and i > should handle all the network and ranges which are inserted by user and > logically are true. network with mask 8, logically is true and having > million available ip address, too. > i just wanna know if there is any solution to improve my performance or not. There is no solution with ISC DHCP. I doubt you'll find other suitable alternatives, but you're free to try of course. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Mon Aug 12 07:44:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9C59FC5D for ; Mon, 12 Aug 2013 07:44:34 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 613B12063 for ; Mon, 12 Aug 2013 07:44:34 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id n10so6764176oag.8 for ; Mon, 12 Aug 2013 00:44:33 -0700 (PDT) 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=b2nBiXqGmXwj9Xm0FL1sFlbv/bzSlGU4NjwOetPYIrI=; b=Rxo0USkLfEZQQfJNKKRurSn3blcWSfm3TNWRrwtpKRhN9geTpNdgdz/jfz/mQjbV9i N08h5+8yIbm0+D886hr0xHVsl3IACtYF6PhAnU1HR/9r/x/X4Krpjs3H9gGnU3gkWt0x OWaKh01s0np74VXNz3awyMA129wx1o8Y1IHVxzyYLKj92xWX2Ce+yTvoD/0x4GvCEjvU PVG0GLnvC57uwWrhbxxNPeSxbClTxKBQUhWcio/BrgbEjPns5FjOZOQT1qu0mo4eZvlt xu8h7PZd79JIKsoDPkgd4s500ssiDE03eagMtY+DYH5NG0LibdsTKkZpeKxPrb0yto6t ppBQ== MIME-Version: 1.0 X-Received: by 10.182.242.37 with SMTP id wn5mr296442obc.56.1376293472933; Mon, 12 Aug 2013 00:44:32 -0700 (PDT) Received: by 10.76.108.143 with HTTP; Mon, 12 Aug 2013 00:44:32 -0700 (PDT) In-Reply-To: <20130812.071303.74723582.sthaug@nethelp.no> References: <20130812.071303.74723582.sthaug@nethelp.no> Date: Mon, 12 Aug 2013 09:44:32 +0200 Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: Andreas Nilsson To: sthaug@nethelp.no Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Olivier Nicole , Olivier Nicole , s m , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Aug 2013 07:44:34 -0000 On Mon, Aug 12, 2013 at 7:13 AM, wrote: > > you're right Olivier, but you know i have a user interface for dhcp and i > > should handle all the network and ranges which are inserted by user and > > logically are true. network with mask 8, logically is true and having > > million available ip address, too. > > i just wanna know if there is any solution to improve my performance or > not. > > There is no solution with ISC DHCP. I doubt you'll find other suitable > alternatives, but you're free to try of course. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > One thing to try is to have more range statements in the block, like: subnet 192.0.0.0 netmask 255.0.0.0 { range 192.0.0.1 192.127.255.255; range 192.128.0.0 192.255.255.255; } Best regards Andreas From owner-freebsd-net@FreeBSD.ORG Mon Aug 12 09:00:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A055BF86 for ; Mon, 12 Aug 2013 09:00:58 +0000 (UTC) (envelope-from sam.gh1986@gmail.com) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2A1C52609 for ; Mon, 12 Aug 2013 09:00:57 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id o10so4573348lbi.26 for ; Mon, 12 Aug 2013 02:00:56 -0700 (PDT) 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=sSzvrst765FSKWmkTySbj89ARoILZMJQcledwGbF5Hg=; b=dcB5pzR4RS0ys6U2Jo9jAANA3F3u94CmYhP1vLOQE1D6NKru8C1xEWdcWtS22Drn76 /cyN/jOMvkp6YdMyBkMikM4P1wMqyZJmwWw/E3c7fKZhvg50w2mHu4RjTK6WPFRePimR a6IfZONo9xXjFoS3fmBMTK0suKQbRPJlQI5xtucqJQKp9shFZmuBu4ZDh+/lO+uArlgH ootZMeGeZYXjjekdW145HYQVYKSQAbWxrdUP+MWTM4W0iIeNanHC/sL8+OzzA3MWexrG wEv1pmH2H6L8aq4pENkI13hXiizxjq1202yt5hXXTLUQf1xsHBZRKae5HEnw75/O0NTx b4Ng== MIME-Version: 1.0 X-Received: by 10.152.9.37 with SMTP id w5mr11004631laa.23.1376298056110; Mon, 12 Aug 2013 02:00:56 -0700 (PDT) Received: by 10.112.147.230 with HTTP; Mon, 12 Aug 2013 02:00:56 -0700 (PDT) In-Reply-To: References: <20130812.071303.74723582.sthaug@nethelp.no> Date: Mon, 12 Aug 2013 13:30:56 +0430 Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: s m To: Andreas Nilsson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Olivier Nicole , FreeBSD Net , Olivier Nicole , sthaug@nethelp.no X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Aug 2013 09:00:58 -0000 thanks Andreas, but it can not help me. it uses all my RAM memory yet:( On Mon, Aug 12, 2013 at 12:14 PM, Andreas Nilsson wrote: > > On Mon, Aug 12, 2013 at 7:13 AM, wrote: > >> > you're right Olivier, but you know i have a user interface for dhcp and >> i >> > should handle all the network and ranges which are inserted by user and >> > logically are true. network with mask 8, logically is true and having >> > million available ip address, too. >> > i just wanna know if there is any solution to improve my performance or >> not. >> >> There is no solution with ISC DHCP. I doubt you'll find other suitable >> alternatives, but you're free to try of course. >> >> Steinar Haug, Nethelp consulting, sthaug@nethelp.no >> >> > One thing to try is to have more range statements in the block, like: > > subnet 192.0.0.0 netmask 255.0.0.0 > { > range 192.0.0.1 192.127.255.255; > range 192.128.0.0 192.255.255.255; > } > > Best regards > Andreas > From owner-freebsd-net@FreeBSD.ORG Mon Aug 12 09:08:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D61D050E for ; Mon, 12 Aug 2013 09:08:17 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A6D726A1 for ; Mon, 12 Aug 2013 09:08:17 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id o6so9469037oag.27 for ; Mon, 12 Aug 2013 02:08:16 -0700 (PDT) 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=WVqT5iWA9wfTnA/Xs+rvTaOVIY2USuMF7W+OM0I8/3Y=; b=lt/Rn1oKO+8c/VRx9yB1XiFWjt6gWtt+hkqSgu47cdSgmZUZeGEMheN6mE/OWpZNH+ K93/XD712vwcSn3Us+lYjSkR5OIIUGa5AArMdtIYCwMNj1PZdFdswjvd64Gn1RQL8IYO jxsG7fr7zNIxbD4ops8aBnmaL+eN2uy6rWo1T3tDBP4QplUbAst/gzmVOOecCnrBl7+c PKlKfuW3EROsm64YBHJ0pGK82qp8tVYrOFPNiCp1hLM/DOkjUtEOVeqrarhkenogfeev zxHlrNkTTjx8Hy1jkI3lkVSLZLzMOXR1MetQT4EU9BbuL1qyERD/6wq3LExzmRalGPRo yDIg== MIME-Version: 1.0 X-Received: by 10.60.51.41 with SMTP id h9mr9988692oeo.49.1376298496700; Mon, 12 Aug 2013 02:08:16 -0700 (PDT) Received: by 10.76.108.143 with HTTP; Mon, 12 Aug 2013 02:08:16 -0700 (PDT) In-Reply-To: References: <20130812.071303.74723582.sthaug@nethelp.no> Date: Mon, 12 Aug 2013 11:08:16 +0200 Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: Andreas Nilsson To: s m Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Olivier Nicole , FreeBSD Net , Olivier Nicole , sthaug@nethelp.no X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Aug 2013 09:08:17 -0000 Well, thats another problem :) At least dhcpd doesn't crash and could deliver the full range of a /8 network. Best regards Andreas On Mon, Aug 12, 2013 at 11:00 AM, s m wrote: > thanks Andreas, but it can not help me. it uses all my RAM memory yet:( > > > On Mon, Aug 12, 2013 at 12:14 PM, Andreas Nilsson wrote: > >> >> On Mon, Aug 12, 2013 at 7:13 AM, wrote: >> >>> > you're right Olivier, but you know i have a user interface for dhcp >>> and i >>> > should handle all the network and ranges which are inserted by user and >>> > logically are true. network with mask 8, logically is true and having >>> > million available ip address, too. >>> > i just wanna know if there is any solution to improve my performance >>> or not. >>> >>> There is no solution with ISC DHCP. I doubt you'll find other suitable >>> alternatives, but you're free to try of course. >>> >>> Steinar Haug, Nethelp consulting, sthaug@nethelp.no >>> >>> >> One thing to try is to have more range statements in the block, like: >> >> subnet 192.0.0.0 netmask 255.0.0.0 >> { >> range 192.0.0.1 192.127.255.255; >> range 192.128.0.0 192.255.255.255; >> } >> >> Best regards >> Andreas >> > > From owner-freebsd-net@FreeBSD.ORG Mon Aug 12 09:18:30 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BFBE5C47 for ; Mon, 12 Aug 2013 09:18:30 +0000 (UTC) (envelope-from sam.gh1986@gmail.com) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 319C2273E for ; Mon, 12 Aug 2013 09:18:30 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id n6so396822lbi.8 for ; Mon, 12 Aug 2013 02:18:28 -0700 (PDT) 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=aw3y2Fhyx65UmW4m/USfBVZHgDGzC1SAuMHgwgUpYb0=; b=mt9F9D9IKZTdO8YKqlj3qZ/UOigVXJFAWH16gQegkfnxaZcTx2Tp5uLcD1pq9Bwkp2 RyapYtvLQmwx2ziKmZ+qlkevIgUYx2WZsR6feMzc9ASCVHY2knqy+gQqJ9Vy4dOsm/Xd GlXwgqPmCLNM1tuTNec1yrTZT6SzMVQrzXZDWH4lNoOvs5onVXl8i1Cu6lQlMBOAJzxg yjv4SSYCSxvkRBSJ2EpFXbM31TTtW/L3g039eVaCaUC5wf90c8sgYr2enW/kX8J97A8o 2PI9tA5Ql4Qd+iTxfaSaQqsa6fxGVucDaiE+awc8Ffkem9tglbL6tQbMfkwLbuV6N2HO b7+g== MIME-Version: 1.0 X-Received: by 10.112.14.102 with SMTP id o6mr9399242lbc.28.1376299108208; Mon, 12 Aug 2013 02:18:28 -0700 (PDT) Received: by 10.112.147.230 with HTTP; Mon, 12 Aug 2013 02:18:28 -0700 (PDT) In-Reply-To: References: <20130812.071303.74723582.sthaug@nethelp.no> Date: Mon, 12 Aug 2013 13:48:28 +0430 Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: s m To: Andreas Nilsson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Olivier Nicole , FreeBSD Net , Olivier Nicole , sthaug@nethelp.no X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Aug 2013 09:18:30 -0000 yup, absolutely right:) is there any way to improve performance??? do you have any suggestion? On Mon, Aug 12, 2013 at 1:38 PM, Andreas Nilsson wrote: > Well, thats another problem :) At least dhcpd doesn't crash and could > deliver the full range of a /8 network. > > Best regards > Andreas > > > > On Mon, Aug 12, 2013 at 11:00 AM, s m wrote: > >> thanks Andreas, but it can not help me. it uses all my RAM memory yet:( >> >> >> On Mon, Aug 12, 2013 at 12:14 PM, Andreas Nilsson wrote: >> >>> >>> On Mon, Aug 12, 2013 at 7:13 AM, wrote: >>> >>>> > you're right Olivier, but you know i have a user interface for dhcp >>>> and i >>>> > should handle all the network and ranges which are inserted by user >>>> and >>>> > logically are true. network with mask 8, logically is true and having >>>> > million available ip address, too. >>>> > i just wanna know if there is any solution to improve my performance >>>> or not. >>>> >>>> There is no solution with ISC DHCP. I doubt you'll find other suitable >>>> alternatives, but you're free to try of course. >>>> >>>> Steinar Haug, Nethelp consulting, sthaug@nethelp.no >>>> >>>> >>> One thing to try is to have more range statements in the block, like: >>> >>> subnet 192.0.0.0 netmask 255.0.0.0 >>> { >>> range 192.0.0.1 192.127.255.255; >>> range 192.128.0.0 192.255.255.255; >>> } >>> >>> Best regards >>> Andreas >>> >> >> > From owner-freebsd-net@FreeBSD.ORG Mon Aug 12 10:17:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0BF4680 for ; Mon, 12 Aug 2013 10:17:14 +0000 (UTC) (envelope-from olivier2553@gmail.com) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE14A2C63 for ; Mon, 12 Aug 2013 10:17:13 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id bq6so912888qab.12 for ; Mon, 12 Aug 2013 03:17:12 -0700 (PDT) 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=hFRK022Vg9L4pvrvVK2w/pK4wIm/iDC8XQBEt10nT5Q=; b=XxlGz1uNUiyQkdLUMOo+REWR2fLEaVEw90yE6fkmqeYEGaaAIA4gsXA0oSNTPKA60F UqmRzPN3Jq70zTn+MiGt8dl2n//B8PXlFyGRwMV4qXO8djbUbVEaiWOSZ5v7ZmSbgF3l A7djfmxVamy5Ij28gTGB+W8OLHMkh36pdApbsZzx0MMX0Gt3dmf3yzdrtQ4d1r0hU+xE RF1MryAOusYfZBPaKjYNgbmWl/IiWTyc9oXTq59Z71ZDK1GvCExJ9PfaBvYH3ZUEUIJV NF1KHn4/YNY0CeXjCFhMtlrBimZsffglIx+C86/qyYg/x8MtYNADG6NgGI9vT4VQR9S+ FdkQ== MIME-Version: 1.0 X-Received: by 10.49.42.103 with SMTP id n7mr13319271qel.75.1376302632363; Mon, 12 Aug 2013 03:17:12 -0700 (PDT) Sender: olivier2553@gmail.com Received: by 10.49.62.41 with HTTP; Mon, 12 Aug 2013 03:17:12 -0700 (PDT) In-Reply-To: References: <20130812.071303.74723582.sthaug@nethelp.no> Date: Mon, 12 Aug 2013 17:17:12 +0700 X-Google-Sender-Auth: nWFtLL9I7s0z4UBf7osxuvVFIeU Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: Olivier Nicole To: s m Content-Type: text/plain; charset=ISO-8859-1 Cc: Olivier Nicole , FreeBSD Net , sthaug@nethelp.no, Andreas Nilsson X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Aug 2013 10:17:14 -0000 Sam, > is there any way to improve performance??? do you have any suggestion? Unless it is on paper, do not even try to offer a /8 network, makes subnets out of it and have as many DHCP servers as you need. It is simply impossible to run a /8 network, so it make no sense offering such a thing. Limit your scripts to what makes sense. Best regards, Olivier > > > On Mon, Aug 12, 2013 at 1:38 PM, Andreas Nilsson wrote: > >> Well, thats another problem :) At least dhcpd doesn't crash and could >> deliver the full range of a /8 network. >> >> Best regards >> Andreas >> >> >> >> On Mon, Aug 12, 2013 at 11:00 AM, s m wrote: >> >>> thanks Andreas, but it can not help me. it uses all my RAM memory yet:( >>> >>> >>> On Mon, Aug 12, 2013 at 12:14 PM, Andreas Nilsson wrote: >>> >>>> >>>> On Mon, Aug 12, 2013 at 7:13 AM, wrote: >>>> >>>>> > you're right Olivier, but you know i have a user interface for dhcp >>>>> and i >>>>> > should handle all the network and ranges which are inserted by user >>>>> and >>>>> > logically are true. network with mask 8, logically is true and having >>>>> > million available ip address, too. >>>>> > i just wanna know if there is any solution to improve my performance >>>>> or not. >>>>> >>>>> There is no solution with ISC DHCP. I doubt you'll find other suitable >>>>> alternatives, but you're free to try of course. >>>>> >>>>> Steinar Haug, Nethelp consulting, sthaug@nethelp.no >>>>> >>>>> >>>> One thing to try is to have more range statements in the block, like: >>>> >>>> subnet 192.0.0.0 netmask 255.0.0.0 >>>> { >>>> range 192.0.0.1 192.127.255.255; >>>> range 192.128.0.0 192.255.255.255; >>>> } >>>> >>>> Best regards >>>> Andreas >>>> >>> >>> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://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 Aug 12 11:06:49 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B56E5AED for ; Mon, 12 Aug 2013 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A1A7D2142 for ; Mon, 12 Aug 2013 11:06:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7CB6n6b085105 for ; Mon, 12 Aug 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7CB6nbU085103 for freebsd-net@FreeBSD.org; Mon, 12 Aug 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Aug 2013 11:06:49 GMT Message-Id: <201308121106.r7CB6nbU085103@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Aug 2013 11:06:49 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/181225 net [infiniband] [patch] unloading ipoib crashes the kerne o kern/181135 net [netmap] [patch] sys/dev/netmap patch for Linux compat o kern/181131 net [netmap] [patch] sys/dev/netmap memory allocation impr o kern/181006 net [run] [patch] mbuf leak in run(4) driver o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 458 problems total. From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 03:12:56 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3DB43C6D; Tue, 13 Aug 2013 03:12:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 11563218C; Tue, 13 Aug 2013 03:12:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7D3Ctf4084996; Tue, 13 Aug 2013 03:12:55 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7D3Ctca084995; Tue, 13 Aug 2013 03:12:55 GMT (envelope-from linimon) Date: Tue, 13 Aug 2013 03:12:55 GMT Message-Id: <201308130312.r7D3Ctca084995@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/181236: [igb] igb driver unstable work X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 03:12:56 -0000 Old Synopsis: IGB driver unstable work New Synopsis: [igb] igb driver unstable work Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Aug 13 03:12:19 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=181236 From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 08:42:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 51C0586B; Tue, 13 Aug 2013 08:42:15 +0000 (UTC) (envelope-from sam.gh1986@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9AE2A243D; Tue, 13 Aug 2013 08:42:14 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id ec20so5671720lab.28 for ; Tue, 13 Aug 2013 01:42:12 -0700 (PDT) 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=KlI7YmVWeU+7UE0QqbqcS1Xn58+/NofBhRrrZVDN90A=; b=d3ZC6Utq5oZ7Aa3lw9m+JdG25P8TkpjI3lrS5uKNOtJGMGLV/z9c56S/T+ayJDKkj9 8+EYUQkWgXUGxPdbUiUr3xLY9BQobGJKvbzQqcx7w8kK/lKkydA5RPPlG9vw75NBMC+E Pw/kqaiSpr2Vt7oitkLqrjsqBgAFbFK6y6j/FYTIZUm+I28imJRN8ytZyA+/3vyNHuUI 6P1ZqPAKx+iFIt9/WvKsdj3axx/8ECEkGZjliaDlaI6BQFt/anHW4n2Xx59Qi7kd2h3T LfSCx0mOf7zfW2CqkSTpX71hQJVljw9D7u4p7tlMwcNUG3l9AfvQi8TvMVVPwmVN6Vsy tI7g== MIME-Version: 1.0 X-Received: by 10.112.24.2 with SMTP id q2mr1054275lbf.34.1376383332522; Tue, 13 Aug 2013 01:42:12 -0700 (PDT) Received: by 10.112.147.230 with HTTP; Tue, 13 Aug 2013 01:42:12 -0700 (PDT) Date: Tue, 13 Aug 2013 13:12:12 +0430 Message-ID: Subject: WIDE-DHCP From: s m To: FreeBSD Net , freebsd-questions Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 08:42:15 -0000 hello guys, does any body use WIDE-DHCP? i installed it on my freebsd 8.2 but don't know how to configure it. i searched a lot but can not find any useful documentation. please let me know if some body configure it or have some application about. thanks in advance SAM From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 08:58:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9080A13B; Tue, 13 Aug 2013 08:58:32 +0000 (UTC) (envelope-from olivier2553@gmail.com) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 420A42542; Tue, 13 Aug 2013 08:58:32 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id bv4so181635qab.8 for ; Tue, 13 Aug 2013 01:58:30 -0700 (PDT) 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=l0JoKH9V3EUPCQyHVQYxczyeVABQTXeqphcipw/9sAw=; b=XOq5LMyyh10YntrXOUGIyiidAW8y0y0kEQ9h5XHkarqRWp3DV4TeBBtJIPD/8VKjnF Xjlx7Kj9auPOdu4EoKRfrsycyC+eACD3XzyLqkEYslLXwPvLlHOj0BAPRlEwyijSVJ1L iXlrNf8ILS0LkN+fYDXwbGr2KzXTZp4ef67EXBZqTHlJfhVtHeBAB25a5oQeX1dj890w bRDKgcnmAZ0HP8HTnZC77aUIZwyzvfDyjYls8XEujixtNN8davHPQ7I153JZ/FVCPuzE OqLJ9qVz2fQ9pvGF7ppdxu6XKgVzFCWqNzokuTJGrndCkx7IqVMCBi1s2L2v8R3zXK4M hhtA== MIME-Version: 1.0 X-Received: by 10.49.84.6 with SMTP id u6mr76939qey.79.1376384310847; Tue, 13 Aug 2013 01:58:30 -0700 (PDT) Sender: olivier2553@gmail.com Received: by 10.49.62.41 with HTTP; Tue, 13 Aug 2013 01:58:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Aug 2013 15:58:30 +0700 X-Google-Sender-Auth: glZfWbXOkWUunUcGwuS40GCCVYk Message-ID: Subject: Re: WIDE-DHCP From: Olivier Nicole To: s m Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-questions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 08:58:32 -0000 Sam, It seems that the distribution includes a directory called db_sample with some tutorials/examples. But it also seems that the last release of wide-dhcp is 16 years old... Olivier On Tue, Aug 13, 2013 at 3:42 PM, s m wrote: > hello guys, > > > does any body use WIDE-DHCP? i installed it on my freebsd 8.2 but don't > know how to configure it. i searched a lot but can not find any useful > documentation. > > please let me know if some body configure it or have some application about. > thanks in advance > SAM > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 09:02:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 060D4521 for ; Tue, 13 Aug 2013 09:02:56 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 4BB5D25C4 for ; Tue, 13 Aug 2013 09:02:54 +0000 (UTC) Received: (qmail 17660 invoked from network); 13 Aug 2013 09:02:47 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 13 Aug 2013 09:02:47 -0000 Date: Tue, 13 Aug 2013 11:02:47 +0200 (CEST) Message-Id: <20130813.110247.74733201.sthaug@nethelp.no> To: olivier.nicole@cs.ait.ac.th Subject: Re: WIDE-DHCP From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, sam.gh1986@gmail.com, freebsd-questions@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 09:02:56 -0000 > It seems that the distribution includes a directory called db_sample > with some tutorials/examples. > > But it also seems that the last release of wide-dhcp is 16 years old... And I also strongly doubt that he's going to have any better luck with his /8 net. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 11:12:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4491D22B; Tue, 13 Aug 2013 11:12:20 +0000 (UTC) (envelope-from sam.gh1986@gmail.com) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9007B2D64; Tue, 13 Aug 2013 11:12:19 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id n6so1428963lbi.36 for ; Tue, 13 Aug 2013 04:12:17 -0700 (PDT) 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=OsTmoheGFwB01bOLzm1MPyh1VnNwqpRshu20+YHs4G8=; b=VzX4MzM8TkkXfhJK93Ao/ya8eHxWmLh6/c7liIjpESgCAs9Qljso76VPxHzEF48vVk KhX8unlfdFbM+ljtmVkom4KP1RxZEgEBIaUYb4vZHAgcfUVg+8MW2oA/jaFk+Y2oYeM1 +t1GownHCOrgV+D30iVu49GSr7FXsuGr3f2Cz3+xWlgDHe7E8NoPCtdjxbrDfv3H2Dyt F7IOkLCqs14PnKuuO6n/bIYpGa3KHWP2cwqqeVJEcRgsxarZ2lIZnx6rI+KTHQAhH6BQ VQOZSsIPe6Z7tyQ+a5LQoEWHaSe29xTI1mGwCOxpALNhol39oDu0OmLnKjilxA7mfA2D AYTg== MIME-Version: 1.0 X-Received: by 10.152.116.109 with SMTP id jv13mr1672651lab.30.1376392337590; Tue, 13 Aug 2013 04:12:17 -0700 (PDT) Received: by 10.112.147.230 with HTTP; Tue, 13 Aug 2013 04:12:17 -0700 (PDT) In-Reply-To: <20130813.110247.74733201.sthaug@nethelp.no> References: <20130813.110247.74733201.sthaug@nethelp.no> Date: Tue, 13 Aug 2013 15:42:17 +0430 Message-ID: Subject: Re: WIDE-DHCP From: s m To: sthaug@nethelp.no Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , Olivier Nicole , freebsd-questions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 11:12:20 -0000 yes, unfortunately it's not well enough for me:(( On Tue, Aug 13, 2013 at 1:32 PM, wrote: > > It seems that the distribution includes a directory called db_sample > > with some tutorials/examples. > > > > But it also seems that the last release of wide-dhcp is 16 years old... > > And I also strongly doubt that he's going to have any better luck > with his /8 net. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 12:11:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 374739E8 for ; Tue, 13 Aug 2013 12:11:44 +0000 (UTC) (envelope-from artemkuchin76@gmail.com) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B2EBD2185 for ; Tue, 13 Aug 2013 12:11:43 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id w20so272432lbh.5 for ; Tue, 13 Aug 2013 05:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=XjTaEJaChlIdhvGyqTyKK9pqmTQaoyGoF05nDnaLfOk=; b=KZ5iyQOWkglIGLf+PNL8rtIMlMYQoWoS7ejGnGqBqhMAIiyn5o7dPhshZg82JIc6uX a4KaNjl8zQhMHFSnn14wbk+09knWr5sDTJ5RkGQNQJU2te2Zf/6w46n0Ryu3HlsnvVrH ZfPRkV8ja72IkWvBnEYftnAhQ6C/W5QyEs6Et4FvaECnFZEuQDCc6LVq5hwoW6omcfDp BH/ilJMcJf4Iy1dDN/ilgSoE8fwtRKKShtLxsdyOCjZfdJhorHxDQIglBo5mDmwbTdZg VoWqpaRoJCuiH8jorPO8SJKFoNMdaQgL5opaY9WZhsQiqg21FfuJsmM8KIN1XRND/oTm YXrA== X-Received: by 10.152.26.72 with SMTP id j8mr3601428lag.19.1376395901631; Tue, 13 Aug 2013 05:11:41 -0700 (PDT) Received: from [192.168.0.12] ([94.228.240.133]) by mx.google.com with ESMTPSA id k9sm13775673lbe.6.2013.08.13.05.11.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Aug 2013 05:11:41 -0700 (PDT) Message-ID: <520A2279.6050600@artem.ru> Date: Tue, 13 Aug 2013 16:11:37 +0400 From: "artem@artem.ru" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Different providers for different nat clients Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 12:11:44 -0000 Hello! I have a strange task and don't understand how to implement such scheme. There is a router with 3 interfaces: IF1: PROVIDER A IF2: PROVIDER B IF3: LAN Clients served via NAT. There are about 15 clients. Now, what i need to do: By default all traffic from all clients goes to PROVIDER A via IF1. But, if total incoming traffic for any particular client becomes over X Mb then that client and only that client must be switch for PROVIDER B. The switch must be automatic and must not use any software on the client side. While i know how to count traffic i don't understand how to route external traffic to/from nat clients on particular external interface. Any idea how it is done? Artem From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 12:19:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C72FCBCC for ; Tue, 13 Aug 2013 12:19:18 +0000 (UTC) (envelope-from olivier2553@gmail.com) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B3C22200 for ; Tue, 13 Aug 2013 12:19:18 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id u12so4039271qcx.35 for ; Tue, 13 Aug 2013 05:19:17 -0700 (PDT) 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=yl1tJAOy7/mPoHvZ1FjsfiIkobvQizDNp4TXClJ5kV4=; b=PMKnDh+5fe6MOy8PyjiGMrFbqaf0/50DgRvipqQxBG0T/LOgYt9Pmbeg8p2/e1+IzV j2DmiUogOpWkkZza+U9TLpHakdpVaGvRP+cWT1+V7UPd69S3l67A+xhY/cV4kLhCI8ly hkiIWHb6iqX/uPYxNksNMF2BXJd9da48dAJ0rwJpmd4isWbl5tMpCx229ffrlY16NQNA RiS/L1RRkSzi+ZbGKI5dF37MlvpjkB1m9DC5XQn6Fyw/gNULkuuQNq7Cr0TDFQzZAkxM XSv4jq+EoEeqz+lMI4QUXXzCpr1xTcNsIQ4b5RQOL4Lo0ewnoi2BatXaSJ758dazPLDn EaeA== MIME-Version: 1.0 X-Received: by 10.229.240.67 with SMTP id kz3mr1037204qcb.29.1376396357718; Tue, 13 Aug 2013 05:19:17 -0700 (PDT) Sender: olivier2553@gmail.com Received: by 10.49.62.41 with HTTP; Tue, 13 Aug 2013 05:19:17 -0700 (PDT) In-Reply-To: <520A2279.6050600@artem.ru> References: <520A2279.6050600@artem.ru> Date: Tue, 13 Aug 2013 19:19:17 +0700 X-Google-Sender-Auth: G7cPRFo1tfplSdPctQ0DuPQpk94 Message-ID: Subject: Re: Different providers for different nat clients From: Olivier Nicole To: "artem@artem.ru" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 12:19:18 -0000 Artem, > I have a strange task and don't understand how to implement such scheme. > > There is a router with 3 interfaces: > > IF1: PROVIDER A > IF2: PROVIDER B > IF3: LAN > > Clients served via NAT. There are about 15 clients. > > Now, what i need to do: > > By default all traffic from all clients goes to PROVIDER A via IF1. > But, if total incoming traffic for any particular client becomes over X Mb > then that client > and only that client must be switch for PROVIDER B. The switch must be > automatic and must > not use any software on the client side. > While i know how to count traffic i don't understand how to route external > traffic to/from > nat clients on particular external interface. > > Any idea how it is done? I would think that you have to dynamically change the configuration of the NAT to associate the client to the IP from provider B. Now, how you do that depends on the NAT software you are using, that ou did not say. Good luck, Olivier From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 12:20:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5AEA9CCC for ; Tue, 13 Aug 2013 12:20:49 +0000 (UTC) (envelope-from artemkuchin76@gmail.com) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D328F2240 for ; Tue, 13 Aug 2013 12:20:48 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id r10so5801559lbi.15 for ; Tue, 13 Aug 2013 05:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=si23NkBAmCWR6EnynCxwQB7no/OJ5rmkywQ1EONYv3U=; b=iOjrOXkZ+/VAvyDLxMVk0oRYph7poMy0QE+C/VuuTn7HMtDCiJFiY5tPyyhxv2u92G 4L2lRUTomt3d6KxW6277VeZa5TKSb6OWkzS0fww0bpn6HsZeeHCSYTpbdDhF090dsA2r RKdMSnHjjbFbpSUbvTwPNebx9p69oqmRHOqy67alSBEQyV4d+n1PgcHeDg1ohVzvL/Ys xXCTeeXND9PMNT+2QnQsrJi3m4ivVqfL9lyvtqtuV0brWRzX1G/eFzqhjeKaRz8q5feh Z0ZVh61VGEaAEzklWN4ebLaIExRf2I0F3R8m/+zCpW33hgVR2oyPW8lEzSaUbv5XZnX6 +J1g== X-Received: by 10.152.3.42 with SMTP id 10mr3683583laz.22.1376396446760; Tue, 13 Aug 2013 05:20:46 -0700 (PDT) Received: from [192.168.0.12] ([94.228.240.133]) by mx.google.com with ESMTPSA id i9sm13977341laa.3.2013.08.13.05.20.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Aug 2013 05:20:46 -0700 (PDT) Message-ID: <520A249A.8030502@artem.ru> Date: Tue, 13 Aug 2013 16:20:42 +0400 From: "artem@artem.ru" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Olivier Nicole Subject: Re: Different providers for different nat clients References: <520A2279.6050600@artem.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 12:20:49 -0000 13.08.2013 16:19, Olivier Nicole пишет: > Artem, > >> I have a strange task and don't understand how to implement such scheme. >> >> There is a router with 3 interfaces: >> >> IF1: PROVIDER A >> IF2: PROVIDER B >> IF3: LAN >> >> Clients served via NAT. There are about 15 clients. >> >> Now, what i need to do: >> >> By default all traffic from all clients goes to PROVIDER A via IF1. >> But, if total incoming traffic for any particular client becomes over X Mb >> then that client >> and only that client must be switch for PROVIDER B. The switch must be >> automatic and must >> not use any software on the client side. >> While i know how to count traffic i don't understand how to route external >> traffic to/from >> nat clients on particular external interface. >> >> Any idea how it is done? > I would think that you have to dynamically change the configuration of > the NAT to associate the client to the IP from provider B. > > Now, how you do that depends on the NAT software you are using, that > ou did not say. > > Good luck, > > Olivier Um.. i was planning to use the included natd But i think it has only one external address to use From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 12:34:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AF797FA for ; Tue, 13 Aug 2013 12:34:08 +0000 (UTC) (envelope-from olivier2553@gmail.com) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 73C692362 for ; Tue, 13 Aug 2013 12:34:08 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id e11so3985886qcx.22 for ; Tue, 13 Aug 2013 05:34:07 -0700 (PDT) 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=L8xeFjzH+iWHdE5cx7le5rSyAB1/wfLQ5SOw2YhraBo=; b=0oAeXu9XB8pZUTd1iczpICJo0M+Vzr6C7T3r7jg5JKc7wqM9R58t0YFl624vrGvtVy LQ++w1aHg8ks8dXN0vKeFiHp3KPPZa94bC+9IuUz5BOOvpxIicr2pUifmXvUj1opfLo8 PSYtoOSnGv1Bx+st09co7CilK2SHy3ttEfC7hn8R7Fat7svJNdIacgLoGJ6jjrrTBXw5 2Ud4nH0Ui88pSWoHh1NSTE2Fi8goykuInNJ65Oe8TbjNlNcL6tH4rKcPSb8fu6EkYSm+ 9U8SDyAjECQXmSPrceyTppPfsA4hE7Q++iPpxybbzPDzvrg9dPN00x4za2y+eBUEDcgg HMNA== MIME-Version: 1.0 X-Received: by 10.49.59.69 with SMTP id x5mr4511928qeq.18.1376397247562; Tue, 13 Aug 2013 05:34:07 -0700 (PDT) Received: by 10.49.62.41 with HTTP; Tue, 13 Aug 2013 05:34:07 -0700 (PDT) In-Reply-To: <520A249A.8030502@artem.ru> References: <520A2279.6050600@artem.ru> <520A249A.8030502@artem.ru> Date: Tue, 13 Aug 2013 19:34:07 +0700 Message-ID: Subject: Re: Different providers for different nat clients From: Olivier Nicole To: "artem@artem.ru" Content-Type: text/plain; charset=ISO-8859-1 Cc: Olivier Nicole , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 12:34:08 -0000 Artem, > Um.. i was planning to use the included natd > But i think it has only one external address to use I think there is a couple of rules to add to ipfw to enable NAT, that maybe where you divert to here or there: ipfw add divert natd all from 192.169.x.y to any via ISPB ipfw add divert natd all from any to any via ISPA That's the direction I would look at. Best regards, Olivier > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 12:46:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 98A463A5 for ; Tue, 13 Aug 2013 12:46:48 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (cust.static.213-3-30-106.swisscomdata.ch [213.3.30.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 139672418 for ; Tue, 13 Aug 2013 12:46:47 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.14.6/8.14.5) with ESMTP id r7DCfrWt010815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Aug 2013 14:41:53 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.6/8.14.5/Submit) id r7DCfr7U016961; Tue, 13 Aug 2013 14:41:53 +0200 (MEST) Date: Tue, 13 Aug 2013 14:41:53 +0200 From: Daniel Hartmeier To: "artem@artem.ru" Subject: Re: Different providers for different nat clients Message-ID: <20130813124153.GA16266@insomnia.benzedrine.cx> References: <520A2279.6050600@artem.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <520A2279.6050600@artem.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 12:46:48 -0000 On Tue, Aug 13, 2013 at 04:11:37PM +0400, artem@artem.ru wrote: > There is a router with 3 interfaces: > > IF1: PROVIDER A > IF2: PROVIDER B > IF3: LAN > > Clients served via NAT. There are about 15 clients. > > Now, what i need to do: > > By default all traffic from all clients goes to PROVIDER A via IF1. > But, if total incoming traffic for any particular client becomes > over X Mb then that client > and only that client must be switch for PROVIDER B. The switch must > be automatic and must > not use any software on the client side. > While i know how to count traffic i don't understand how to route > external traffic to/from > nat clients on particular external interface. > > Any idea how it is done? This is called source-based routing, and at least pf and ipfw support it. Using pf it could look like table nat on IF1 from !IF1 -> IF1 nat on IF2 from !IF2 -> IF2 pass in on IF3 route-to (IF2 GW2) from with the default route going through IF1 to GW1. To add a client to the table, use pfctl -t overquota -Ta 192.168.2.3 Subsequent new connections will go out through the second provider. Existing prior connections will continue to to through the first provider, unless you explicitly remove the sessions, as in pfctl -k 192.168.2.3 Daniel From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 13:35:01 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6154E29F for ; Tue, 13 Aug 2013 13:35:01 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (cust.static.213-3-30-106.swisscomdata.ch [213.3.30.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF33B2744 for ; Tue, 13 Aug 2013 13:35:00 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.14.6/8.14.5) with ESMTP id r7DDYxhF018125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Aug 2013 15:34:59 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.6/8.14.5/Submit) id r7DDYws0025166; Tue, 13 Aug 2013 15:34:58 +0200 (MEST) Date: Tue, 13 Aug 2013 15:34:58 +0200 From: Daniel Hartmeier To: Karl Pielorz Subject: Re: Create CARP interface in state INIT? Message-ID: <20130813133458.GA31184@insomnia.benzedrine.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 13:35:01 -0000 On Thu, Aug 08, 2013 at 01:11:58PM +0100, Karl Pielorz wrote: > Is there any way from rc.conf of creating a carp interface in the > 'down' state - i.e. INIT? I think any interface configured with ifconfig_* in rc.conf will cause an explicit additional "ifconfig up" call from /etc/network.subr. Furthermore, ifconfig itself will add "up" when setting the IP address. So, don't configure the carp interface in rc.conf, but do it in /etc/rc.local, and be careful to add the address while the vhid is not yet configured, as in: ifconfig carp0 create ifconfig carp0 inet 192.168.107.21 ifconfig carp0 down ifconfig carp0 vhid 21 pass secret advskew 100 HTH, Daniel From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 17:28:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1A963DC8 for ; Tue, 13 Aug 2013 17:28:13 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D4EB2266F for ; Tue, 13 Aug 2013 17:28:12 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r7DHBvlB013510 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Aug 2013 10:12:01 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <520A68D8.20402@freebsd.org> Date: Wed, 14 Aug 2013 01:11:52 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Olivier Nicole Subject: Re: Different providers for different nat clients References: <520A2279.6050600@artem.ru> <520A249A.8030502@artem.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Olivier Nicole , FreeBSD Net , "artem@artem.ru" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 17:28:13 -0000 On 8/13/13 8:34 PM, Olivier Nicole wrote: > Artem, > >> Um.. i was planning to use the included natd >> But i think it has only one external address to use > I think there is a couple of rules to add to ipfw to enable NAT, that > maybe where you divert to here or there: > > ipfw add divert natd all from 192.169.x.y to any via ISPB > ipfw add divert natd all from any to any via ISPA > > That's the direction I would look at. Ok here are some thoughts.. you want existing sessions from the offending client to continue to run through the original interface, or their session will immediately die. so you need to use dynamic session based routing. one way to so this is using the keep-state and check state rules in ipfw. if you do a rule like check-state fwd ISP2 ip from table(1) to any in recv $LAN keep-state fwd ISP1 ip from any to any in recv $LAN keep-state then that session will continue to do that even if the contents of table(1) change. then you can use NAT rules on each $ISP interface to ensure that packets get translated correctly it's up to you to arrange the contents of the table.. I can't remember off hand whether a firewall pass terminates on a fwd rule match or not.. you may want to check that. I think you should divide your rules up into rules for each interface and direction using skipto, and then in each section have specialist rules for just that traffic. so with 3 interfaces you would have 6 sets of rules, (say 1000, 2000, 3000, 4000, 5000 and 6000) and the very first rules would be: skipto 1000 ip from any to any in recv $LAN skipto 2000 ip from any to any out xmit $LAN skipto 3000 ip from any to any in recv $ISP1 skipto 4000 ip from any to any out xmit $ISP1 skipto 5000 ip from any to any in recv $ISP2 skipto 6000 ip from any to any out xmit $ISP2 [handle loopback packets here] at 1000 you have the rules above. at 3000 , 4000, 5000 and 6000 you have NAT rules (with different NAT instances for each interface. you can use whatever method you like (e.g. dummynet accounting?) to work out how much traffic is going, and add and remove entries in the table. remember though to make sure exisiting sessions don't get switched! Julian > > Best regards, > > Olivier > >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 17:29:54 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41A056D for ; Tue, 13 Aug 2013 17:29:54 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 170DA2684 for ; Tue, 13 Aug 2013 17:29:53 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r7DHTnWO013577 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 13 Aug 2013 10:29:52 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <520A6D07.5080106@freebsd.org> Date: Wed, 14 Aug 2013 01:29:43 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: FreeBSD Net Subject: TSO and FreeBSD vs Linux Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 17:29:54 -0000 I have been tracking down a performance embarrassment on AMAZON EC2 and have found it I think. Our OS cousins over at Linux land have implemented some interesting behaviour when TSO is in use. They seem to aggregate ACKS when there is a lot of traffic so that they can create the largest possible TSO packet. We on the other hand respond to each and every returning ACK, as it arrives and thus generally fall into the behaviour of sending a bunch of small packets, the size of each ack. for two examples look at: http://www.freebsd.org/~julian/LvsF-tcp-start.tiff and http://www.freebsd.org/~julian/LvsF-tcp.tiff in each case, we can see FreeBSD on the left and Linux on the right. The first case shows the case as the sessions start, and the second case shows some distance later (when the sequence numbers wrap around.. no particular reason to use that, it was just fun to see). In both cases you can see that each Linux packet (white)(once they have got going) is responding to multiple bumps in the send window sequence number (green and yellow lines) (representing the arrival of several ACKs) while FreeBSD produces a whole bunch of smaller packets, slavishly following exactly the size of each incoming ack.. This gives us quite a performance debt. Notice that this behaviour in Linux seems to be modal.. it seems to 'switch on' a little bit into the 'starting' trace. In addition, you can see also that Linux gets going faster even in the beginning where TSO isn't in play, by sending a lot more packets up-front. (of course the wisdom of this can be argued). Has anyone done any work on aggregating ACKs, or delaying responding to them? Julian (Who's suspecting he's about to find out more about TSO and the send path, than he ever wanted to). From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 17:37:14 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3308A51A; Tue, 13 Aug 2013 17:37:14 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0770B280D; Tue, 13 Aug 2013 17:37:14 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id up15so8255868pbc.12 for ; Tue, 13 Aug 2013 10:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZnzV8ewOQvghIOJufEMqoGkouN/MTO6oUntCIWiXEeI=; b=t/hu0cESgRlmwk0irDBSkzZ71z01ERxcV6Qa85Uvatoef5kEhr5JTqLeF4lSrkaGA+ tgWaGhGsYbrgztlzw4I6PjRBv/1BNhmFpUzqDXDCEsHzhV6ah5qf2T6Oi87+5A+WhiGy 62vLkFlJUoj22oSjCjdSfmaxl4ZKZtuXGmHOiktMBHDN/vdYjx9Hb2kYWU4joralJvSZ Xh7keyMWhLE/BVu946Ym0zPaeZZffo7bN3j9THZoefW2tAtNi/vH98L85Nr4+wzgktY6 XfT3dFE2oKFrB9c/jOuw+/lxeIW14VluWi+nApfRZ/B/xmwOvO/yoQOM4EPmx6+r+FqS 6Dxw== X-Received: by 10.67.23.36 with SMTP id hx4mr5697320pad.54.1376415433636; Tue, 13 Aug 2013 10:37:13 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id vu5sm48013071pab.10.2013.08.13.10.37.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Aug 2013 10:37:12 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <520A6EC6.6050208@FreeBSD.org> Date: Tue, 13 Aug 2013 10:37:10 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130808 Thunderbird/17.0.8 MIME-Version: 1.0 To: Julian Elischer Subject: Re: TSO and FreeBSD vs Linux References: <520A6D07.5080106@freebsd.org> In-Reply-To: <520A6D07.5080106@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 17:37:14 -0000 On 08/13/13 10:29, Julian Elischer wrote: .. > > Has anyone done any work on aggregating ACKs, or delaying responding to > them? If LRO is enabled on the FreeBSD receiver, ACKs are already aggregated (a duplicate ACK will result in an immediate flush though.) See tcp_lro_rx. Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 17:37:25 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 379265AD for ; Tue, 13 Aug 2013 17:37:25 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C968C2813 for ; Tue, 13 Aug 2013 17:37:24 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r7DHbKAP013619 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 13 Aug 2013 10:37:23 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <520A6ECA.5090307@freebsd.org> Date: Wed, 14 Aug 2013 01:37:14 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: FreeBSD Net Subject: Re: TSO and FreeBSD vs Linux References: <520A6D07.5080106@freebsd.org> In-Reply-To: <520A6D07.5080106@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 17:37:25 -0000 On 8/14/13 1:29 AM, Julian Elischer wrote: > I have been tracking down a performance embarrassment on AMAZON EC2 > and have found it I think. > Our OS cousins over at Linux land have implemented some interesting > behaviour when TSO is in use. > > They seem to aggregate ACKS when there is a lot of traffic so that > they can create the > largest possible TSO packet. We on the other hand respond to each > and every returning ACK, as it arrives and thus generally fall into > the behaviour of sending a bunch of small packets, the size of each > ack. > > for two examples look at: > > > http://www.freebsd.org/~julian/LvsF-tcp-start.tiff > and > http://www.freebsd.org/~julian/LvsF-tcp.tiff some people have troubel with tiff, so here they are a jpeg. http://www.freebsd.org/~julian/LvsF-tcp-start.jpg and http://www.freebsd.org/~julian/LvsF-tcp.jpg > > in each case, we can see FreeBSD on the left and Linux on the right. > > The first case shows the case as the sessions start, and the second > case shows > some distance later (when the sequence numbers wrap around.. no > particular > reason to use that, it was just fun to see). > In both cases you can see that each Linux packet (white)(once they > have got > going) is responding to multiple bumps in the send window sequence > number (green and yellow lines) (representing the arrival of several > ACKs) > while FreeBSD produces a whole bunch of smaller packets, slavishly > following > exactly the size of each incoming ack.. This gives us quite a > performance debt. > Notice that this behaviour in Linux seems to be modal.. it seems to > 'switch on' a little bit > into the 'starting' trace. > > In addition, you can see also that Linux gets going faster even in > the beginning where > TSO isn't in play, by sending a lot more packets up-front. (of > course the wisdom of this > can be argued). > > Has anyone done any work on aggregating ACKs, or delaying responding > to them? > > Julian > (Who's suspecting he's about to find out more about TSO and the send > path, than he ever wanted to). > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Tue Aug 13 17:54:52 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2C498D3A; Tue, 13 Aug 2013 17:54:52 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B1372940; Tue, 13 Aug 2013 17:54:50 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id fn20so4772114lab.37 for ; Tue, 13 Aug 2013 10:54:49 -0700 (PDT) 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=pSnNib9S2w1gAnv7i7stZS/k2Qn8pOUoZ/Dd34nH+WE=; b=MYjIOM7WcIpEyjIgli4mnPJaPRZT24dAb5ec6mmm6GVxb4NkIwUXi+Wuk0a9L1MLHn tobvF3o5t/i9PEvo6JGRaPHTR/X0btRBMZm6V9UpvwsVKDTD/BfaQBVzFj0YbFX7yYco 5gTP8K9EmUs1tyDkfPIxX9IE+ucIzHkLzni5e8QGno7gfTcLjiaQgmv86BlyGSodDSr4 2ZhmOCB1wDSkxHANMxG+ILurC2i4TEfheoLCqPISsRTUw9wNmmpAVVOgKQGy+5mn9USL c/L/G2D6pFi6dgrVuzDUpeHJcRV6l/P3c060a9zO3Ehv55S0+ikJ4dSYM1/9DKtD8Euz AwdA== MIME-Version: 1.0 X-Received: by 10.152.22.65 with SMTP id b1mr1237582laf.46.1376416488981; Tue, 13 Aug 2013 10:54:48 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Tue, 13 Aug 2013 10:54:48 -0700 (PDT) In-Reply-To: <520A6EC6.6050208@FreeBSD.org> References: <520A6D07.5080106@freebsd.org> <520A6EC6.6050208@FreeBSD.org> Date: Tue, 13 Aug 2013 19:54:48 +0200 X-Google-Sender-Auth: 37dp9bqh8yyFMQuCenuMUsywv2E Message-ID: Subject: Re: TSO and FreeBSD vs Linux From: Luigi Rizzo To: Navdeep Parhar Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Aug 2013 17:54:52 -0000 On Tue, Aug 13, 2013 at 7:37 PM, Navdeep Parhar wrote: > On 08/13/13 10:29, Julian Elischer wrote: > .. > > > > Has anyone done any work on aggregating ACKs, or delaying responding to > > them? > > If LRO is enabled on the FreeBSD receiver, ACKs are already aggregated > (a duplicate ACK will result in an immediate flush though.) See > tcp_lro_rx. > >From what I have heard (no direct experience though), when TSO is enabled linux may decide to hold a transmission in the hope of getting more acks in the future hence a larger segment sent in one shot. I am not sure i find similar code in FreeBSD; there is something mentioned in tcp_output() but then the check only seems to be for t_maxseg /* * Sender silly window avoidance. We transmit under the following * conditions when len is non-zero: * * - We have a full segment (or more with TSO) * - This is the last buffer in a write()/send() and we are * either idle or running NODELAY * - we've timed out (e.g. persist timer) * - we have more then 1/2 the maximum send window's worth of * data (receiver may be limited the window size) * - we need to retransmit */ if (len) { if (len >= tp->t_maxseg) goto send; /* and the t_maxseg seems to be capped to the mss. This could be implemented in tcp_output(), i suppose. cheers luigi > Regards, > Navdeep > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://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-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 00:51:24 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 94F6BCFF; Wed, 14 Aug 2013 00:51:24 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 380BF220F; Wed, 14 Aug 2013 00:51:23 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r7E0pJh7014723 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Aug 2013 17:51:21 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <520AD486.6050708@freebsd.org> Date: Wed, 14 Aug 2013 08:51:18 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Navdeep Parhar Subject: Re: TSO and FreeBSD vs Linux References: <520A6D07.5080106@freebsd.org> <520A6EC6.6050208@FreeBSD.org> In-Reply-To: <520A6EC6.6050208@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 00:51:24 -0000 On 8/14/13 1:37 AM, Navdeep Parhar wrote: > On 08/13/13 10:29, Julian Elischer wrote: > .. >> Has anyone done any work on aggregating ACKs, or delaying responding to >> them? > If LRO is enabled on the FreeBSD receiver, ACKs are already aggregated > (a duplicate ACK will result in an immediate flush though.) See tcp_lro_rx. not always, , certainly not with XEN (xn0) on EC2. > > Regards, > Navdeep > From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 00:58:40 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 90CA8E06; Wed, 14 Aug 2013 00:58:40 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 634EE224D; Wed, 14 Aug 2013 00:58:40 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id v10so5635701pde.24 for ; Tue, 13 Aug 2013 17:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=l0gtmYI8w3ow18b8485TngBkot2QGeS3/hbuRwHpMzo=; b=g5Jmf9bMZPa3sfBIZzjpeAyD4HNglObwCmw9ukaz4DzPOVDuHaMOLumyT0QUIGZl7Q P1+Hmbg+bELRyVwwCtEhZTRV/7uSPlrEsY+YFeFBGnmo68xxDVAjuR2IGPu7hkvYxpaG couFwjd86IwqvloIhpzpzWaP9sXNjlxezXBSLgZvR2Ljlfp9MXMJ25p2y/rbA6vEfNR7 dGb6cp6I7kTt9C6x2Rev+t9WqydqYuw9aKAILjw4DEYiVZMGAVdXzZrFTt3fXpsWY1nN fmoibM5/kvMKsezCUVooyKrwlSXj0fp1DT4THBOCycUXc/WiiYL+iT/x5uZeZ6VoW3yF 6Gpw== X-Received: by 10.68.252.233 with SMTP id zv9mr7074648pbc.69.1376441920125; Tue, 13 Aug 2013 17:58:40 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id z14sm46766146pbt.0.2013.08.13.17.58.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Aug 2013 17:58:38 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <520AD63C.1080801@FreeBSD.org> Date: Tue, 13 Aug 2013 17:58:36 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130808 Thunderbird/17.0.8 MIME-Version: 1.0 To: Julian Elischer Subject: Re: TSO and FreeBSD vs Linux References: <520A6D07.5080106@freebsd.org> <520A6EC6.6050208@FreeBSD.org> <520AD486.6050708@freebsd.org> In-Reply-To: <520AD486.6050708@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 00:58:40 -0000 On 08/13/13 17:51, Julian Elischer wrote: > On 8/14/13 1:37 AM, Navdeep Parhar wrote: >> On 08/13/13 10:29, Julian Elischer wrote: >> .. >>> Has anyone done any work on aggregating ACKs, or delaying responding to >>> them? >> If LRO is enabled on the FreeBSD receiver, ACKs are already aggregated >> (a duplicate ACK will result in an immediate flush though.) See >> tcp_lro_rx. > not always, , certainly not with XEN (xn0) on EC2. It will vary from driver to driver and how many frames a driver gets to (or chooses to) process in one run of its interrupt handler. From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 02:08:24 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41030DAA; Wed, 14 Aug 2013 02:08:24 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B79225EF; Wed, 14 Aug 2013 02:08:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7E28N6Q007205; Wed, 14 Aug 2013 02:08:23 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7E28N6A007204; Wed, 14 Aug 2013 02:08:23 GMT (envelope-from linimon) Date: Wed, 14 Aug 2013 02:08:23 GMT Message-Id: <201308140208.r7E28N6A007204@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/181257: [bge] bge link status change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 02:08:24 -0000 Old Synopsis: bge link status change New Synopsis: [bge] bge link status change Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Aug 14 02:08:11 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=181257 From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 02:45:46 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 768E86D3; Wed, 14 Aug 2013 02:45:46 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 39D3C27D1; Wed, 14 Aug 2013 02:45:46 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 90A2E7E88D; Wed, 14 Aug 2013 12:36:31 +1000 (EST) Message-ID: <520AED2F.4050001@freebsd.org> Date: Wed, 14 Aug 2013 12:36:31 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130801 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andre Oppermann Subject: TCP Initial Window 10 MFC (was: Re: svn commit: r252789 - stable/9/sys/netinet) References: <201307051458.r65EwObo066269@svn.freebsd.org> In-Reply-To: <201307051458.r65EwObo066269@svn.freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 02:45:46 -0000 Hi Andre, [RE team is BCCed so they're aware of this discussion] On 07/06/13 00:58, Andre Oppermann wrote: > Author: andre > Date: Fri Jul 5 14:58:24 2013 > New Revision: 252789 > URL: http://svnweb.freebsd.org/changeset/base/252789 > > Log: > MFC r242266: > > Increase the initial CWND to 10 segments as defined in IETF TCPM > draft-ietf-tcpm-initcwnd-05. It explains why the increased initial > window improves the overall performance of many web services without > risking congestion collapse. > > As long as it remains a draft it is placed under a sysctl marking it > as experimental: > net.inet.tcp.experimental.initcwnd10 = 1 > When it becomes an official RFC soon the sysctl will be changed to > the RFC number and moved to net.inet.tcp. > > This implementation differs from the RFC draft in that it is a bit > more conservative in the case of packet loss on SYN or SYN|ACK because > we haven't reduced the default RTO to 1 second yet. Also the restart > window isn't yet increased as allowed. Both will be adjusted with > upcoming changes. > > Is is enabled by default. In Linux it is enabled since kernel 3.0. I haven't been fully alert to FreeBSD happenings this year so apologies for bringing this up so long after the MFC. I don't think this change should have been MFCed, at least not in its current form. Enabling the switch to IW=10 on a stable branch is inappropriate IMO. I also think the "net.inet.tcp.experimental" sysctl branch is poorly named as per the important discussion we had back in February [1]. I would really prefer we didn't get stuck having to keep it around by making a stable release with it being present. I think this commit should be backed out of stable/9 and more importantly, 9.2-RELEASE. As an aside, I am intending to follow up to the Feb discussion with a patch that implements the basic infrastructure I proposed so that we can continue that discussion. Thoughts? Cheers, Lawrence [1] http://lists.freebsd.org/pipermail/freebsd-net/2013-February/034698.html From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 03:39:26 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C375D1B6; Wed, 14 Aug 2013 03:39:26 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 520B62AAD; Wed, 14 Aug 2013 03:39:25 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 889B77E81E; Wed, 14 Aug 2013 13:39:21 +1000 (EST) Message-ID: <520AFBE8.1090109@freebsd.org> Date: Wed, 14 Aug 2013 13:39:20 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130801 Thunderbird/17.0.7 MIME-Version: 1.0 To: Julian Elischer Subject: Re: TSO and FreeBSD vs Linux References: <520A6D07.5080106@freebsd.org> In-Reply-To: <520A6D07.5080106@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 03:39:26 -0000 On 08/14/13 03:29, Julian Elischer wrote: > I have been tracking down a performance embarrassment on AMAZON EC2 and > have found it I think. Let us please avoid conflating performance with throughput. The behaviour you go on to describe as a performance embarrassment is actually a throughput difference, and the FreeBSD behaviour you're describing is essentially sacrificing throughput and CPU cycles for lower latency. That may not be a trade-off you like, but it is an important factor in this discussion. Don't fall into the trap of labelling Linux's propensity for maximising throughput as superior to an alternative approach which strikes a different balance. It all depends on the use case. > Our OS cousins over at Linux land have implemented some interesting > behaviour when TSO is in use. > > They seem to aggregate ACKS when there is a lot of traffic so that they > can create the > largest possible TSO packet. We on the other hand respond to each and > every returning ACK, as it arrives and thus generally fall into the > behaviour of sending a bunch of small packets, the size of each ack. There's a thing controlled by ethtool called GRO (generic receive offload) which appears to be enabled by default on at least Ubuntu and I guess other Linux's too. It's responsible for aggregating ACKs and data to batch them up the stack if the driver doesn't provide a hardware offload implementation. Try rerunning your experiments with the ACK batching disabled on the Linux host to get an additional comparison point. > for two examples look at: > > > http://www.freebsd.org/~julian/LvsF-tcp-start.tiff > and > http://www.freebsd.org/~julian/LvsF-tcp.tiff > > in each case, we can see FreeBSD on the left and Linux on the right. > > The first case shows the case as the sessions start, and the second case > shows > some distance later (when the sequence numbers wrap around.. no particular > reason to use that, it was just fun to see). > In both cases you can see that each Linux packet (white)(once they have got > going) is responding to multiple bumps in the send window sequence > number (green and yellow lines) (representing the arrival of several ACKs) > while FreeBSD produces a whole bunch of smaller packets, slavishly > following > exactly the size of each incoming ack.. This gives us quite a > performance debt. Again, please s/performance/what-you-really-mean/ here. > Notice that this behaviour in Linux seems to be modal.. it seems to > 'switch on' a little bit > into the 'starting' trace. > > In addition, you can see also that Linux gets going faster even in the > beginning where > TSO isn't in play, by sending a lot more packets up-front. (of course > the wisdom of this > can be argued). They switched to using an initial window of 10 segments some time ago. FreeBSD starts with 3 or more recently, 10 if you're running recent 9-STABLE or 10-CURRENT. > Has anyone done any work on aggregating ACKs, or delaying responding to > them? As noted by Navdeep, we already have the code to aggregate ACKs in our software LRO implementation. The bigger problem is that appropriate byte counting places a default 2*MSS limit on the amount of ACKed data the window can grow by i.e. if an ACK for 64k of data comes up the stack, we'll grow the window by 2 segments worth of data in response. That needs to be addressed - we could send the ACK count up with the aggregated single ACK or just ignore abc_l_var when LRO is in use for a connection. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 06:33:15 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 531BCB69; Wed, 14 Aug 2013 06:33:15 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3132D2214; Wed, 14 Aug 2013 06:33:14 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r7E6XADl015797 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Aug 2013 23:33:12 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <520B24A0.4000706@freebsd.org> Date: Wed, 14 Aug 2013 14:33:04 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Lawrence Stewart Subject: Re: TSO and FreeBSD vs Linux References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> In-Reply-To: <520AFBE8.1090109@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 06:33:15 -0000 On 8/14/13 11:39 AM, Lawrence Stewart wrote: > On 08/14/13 03:29, Julian Elischer wrote: >> I have been tracking down a performance embarrassment on AMAZON EC2 and >> have found it I think. > Let us please avoid conflating performance with throughput. The > behaviour you go on to describe as a performance embarrassment is > actually a throughput difference, and the FreeBSD behaviour you're > describing is essentially sacrificing throughput and CPU cycles for > lower latency. That may not be a trade-off you like, but it is an > important factor in this discussion. it was an embarrassment in that in one class of test we performed very poorly. It was not a disaster or a show-stopper, but for our product it is a critical number. It is a throughput difference, as you say but that is a very important part of performance... The latency of linux didn't seem to be any worse than FreeBSD, just the throughput was a lot higher in the same scenario. > > Don't fall into the trap of labelling Linux's propensity for maximising > throughput as superior to an alternative approach which strikes a > different balance. It all depends on the use case. well the linux balance seems t be "be better all around" at this moment so that is embarrassing. :-) I could see no latency reversion. > >> Our OS cousins over at Linux land have implemented some interesting >> behaviour when TSO is in use. >> >> They seem to aggregate ACKS when there is a lot of traffic so that they >> can create the >> largest possible TSO packet. We on the other hand respond to each and >> every returning ACK, as it arrives and thus generally fall into the >> behaviour of sending a bunch of small packets, the size of each ack. > There's a thing controlled by ethtool called GRO (generic receive > offload) which appears to be enabled by default on at least Ubuntu and I > guess other Linux's too. It's responsible for aggregating ACKs and data > to batch them up the stack if the driver doesn't provide a hardware > offload implementation. Try rerunning your experiments with the ACK > batching disabled on the Linux host to get an additional comparison point. I will try that as soon as I get back to the machines in question. >> for two examples look at: >> >> >> http://www.freebsd.org/~julian/LvsF-tcp-start.tiff >> and >> http://www.freebsd.org/~julian/LvsF-tcp.tiff >> >> in each case, we can see FreeBSD on the left and Linux on the right. >> >> The first case shows the case as the sessions start, and the second case >> shows >> some distance later (when the sequence numbers wrap around.. no particular >> reason to use that, it was just fun to see). >> In both cases you can see that each Linux packet (white)(once they have got >> going) is responding to multiple bumps in the send window sequence >> number (green and yellow lines) (representing the arrival of several ACKs) >> while FreeBSD produces a whole bunch of smaller packets, slavishly >> following >> exactly the size of each incoming ack.. This gives us quite a >> performance debt. > Again, please s/performance/what-you-really-mean/ here. ok, In my tests this makes FreeBSD data transfers much slower, by as much as 60%. > >> Notice that this behaviour in Linux seems to be modal.. it seems to >> 'switch on' a little bit >> into the 'starting' trace. >> >> In addition, you can see also that Linux gets going faster even in the >> beginning where >> TSO isn't in play, by sending a lot more packets up-front. (of course >> the wisdom of this >> can be argued). > They switched to using an initial window of 10 segments some time ago. > FreeBSD starts with 3 or more recently, 10 if you're running recent > 9-STABLE or 10-CURRENT. I tried setting initial values as shown: net.inet.tcp.local_slowstart_flightsize: 10 net.inet.tcp.slowstart_flightsize: 10 it didn't seem to make too much difference but I will redo the test. > >> Has anyone done any work on aggregating ACKs, or delaying responding to >> them? > As noted by Navdeep, we already have the code to aggregate ACKs in our > software LRO implementation. The bigger problem is that appropriate byte > counting places a default 2*MSS limit on the amount of ACKed data the > window can grow by i.e. if an ACK for 64k of data comes up the stack, > we'll grow the window by 2 segments worth of data in response. That > needs to be addressed - we could send the ACK count up with the > aggregated single ACK or just ignore abc_l_var when LRO is in use for a > connection. so, does "Software LRO" mean that LRO on hte NIC should be ON or OFF to see this? > > Cheers, > Lawrence > > From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 07:23:06 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6FA6F381; Wed, 14 Aug 2013 07:23:06 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id F21DE243C; Wed, 14 Aug 2013 07:23:05 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 880D57E84A; Wed, 14 Aug 2013 17:23:02 +1000 (EST) Message-ID: <520B3056.1000804@freebsd.org> Date: Wed, 14 Aug 2013 17:23:02 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130801 Thunderbird/17.0.7 MIME-Version: 1.0 To: Julian Elischer Subject: Re: TSO and FreeBSD vs Linux References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> In-Reply-To: <520B24A0.4000706@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 07:23:06 -0000 On 08/14/13 16:33, Julian Elischer wrote: > On 8/14/13 11:39 AM, Lawrence Stewart wrote: >> On 08/14/13 03:29, Julian Elischer wrote: >>> I have been tracking down a performance embarrassment on AMAZON EC2 and >>> have found it I think. >> Let us please avoid conflating performance with throughput. The >> behaviour you go on to describe as a performance embarrassment is >> actually a throughput difference, and the FreeBSD behaviour you're >> describing is essentially sacrificing throughput and CPU cycles for >> lower latency. That may not be a trade-off you like, but it is an >> important factor in this discussion. > it was an embarrassment in that in one class of test we performed very > poorly. > It was not a disaster or a show-stopper, but for our product it is a > critical number. Sure, there's nothing wrong with holding throughput up as a key performance metric for your use case. I'm just trying to pre-empt a discussion that focuses on one metric and fails to consider the bigger picture. > It is a throughput difference, as you say but that is a very important > part of performance... > The latency of linux didn't seem to be any worse > than FreeBSD, just the throughput was a lot higher in the same scenario. The latency must increase when you delay packets in order to coalesce them. Whether you were able to perceive that or not with the bulk send type testing and measurement that you're doing is a separate issue. >> Don't fall into the trap of labelling Linux's propensity for maximising >> throughput as superior to an alternative approach which strikes a >> different balance. It all depends on the use case. > well the linux balance seems t be "be better all around" at this moment > so that is > embarrassing. :-) Better all round for you? Seems to be the case. Better all round for everyone? No. Linux's choice of CUBIC as the default congestion control algorithm is also a choice that maximises throughput but has side effects which IMO are quite unfortunate. > I could see no latency reversion. You wouldn't because it would be practically invisible in the sorts of tests/measurements you're doing. Our good friends over at HRT on the other hand would be far more likely to care about latency on the order of microseconds. Again, the use case matters a lot. [snip] >>> Notice that this behaviour in Linux seems to be modal.. it seems to >>> 'switch on' a little bit >>> into the 'starting' trace. >>> >>> In addition, you can see also that Linux gets going faster even in the >>> beginning where >>> TSO isn't in play, by sending a lot more packets up-front. (of course >>> the wisdom of this >>> can be argued). >> They switched to using an initial window of 10 segments some time ago. >> FreeBSD starts with 3 or more recently, 10 if you're running recent >> 9-STABLE or 10-CURRENT. > I tried setting initial values as shown: > net.inet.tcp.local_slowstart_flightsize: 10 > net.inet.tcp.slowstart_flightsize: 10 > it didn't seem to make too much difference but I will redo the test. Assuming this is still FreeBSD 8.0 as you mentioned out-of-band, changing those variables without disabling rfc3390 will have no effect. >>> Has anyone done any work on aggregating ACKs, or delaying responding to >>> them? >> As noted by Navdeep, we already have the code to aggregate ACKs in our >> software LRO implementation. The bigger problem is that appropriate byte >> counting places a default 2*MSS limit on the amount of ACKed data the >> window can grow by i.e. if an ACK for 64k of data comes up the stack, >> we'll grow the window by 2 segments worth of data in response. That >> needs to be addressed - we could send the ACK count up with the >> aggregated single ACK or just ignore abc_l_var when LRO is in use for a >> connection. BTW, as a work around for the appropriate byte counting issue, you can crank net.inet.tcp.abc_l_var up to the number of MSS segments you wish to allow it to increase the window by (per ack). If LRO is aggregating 64 on-wire acks into 1 mega ack, you should set abc_l_var=64. > so, does "Software LRO" mean that LRO on hte NIC should be ON or OFF to > see this? I think (check the driver code in question as I'm not sure) that if you "ifconfig lro" and the driver has hardware support or has been made aware of our software implementation, it should DTRT. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 08:20:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6EFD8FF7 for ; Wed, 14 Aug 2013 08:20:15 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 32CDE266E for ; Wed, 14 Aug 2013 08:20:15 +0000 (UTC) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V9WJP-0007Ax-Fn; Wed, 14 Aug 2013 10:20:11 +0200 Message-ID: <520B3DB8.20502@gont.com.ar> Date: Wed, 14 Aug 2013 05:20:08 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: FreeBSD Net Subject: Fwd: RFC 6980 on Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery References: <20130813221321.AEA1AB1E003@rfc-editor.org> In-Reply-To: <20130813221321.AEA1AB1E003@rfc-editor.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 08:20:15 -0000 Folks, FYI. -- this is an important piece when it comes to First Hop (i.e., "local link") Security. Cheers, Fernando -------- Original Message -------- Subject: RFC 6980 on Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery Date: Tue, 13 Aug 2013 15:13:21 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: drafts-update-ref@iana.org, ipv6@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6980 Title: Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery Author: F. Gont Status: Standards Track Stream: IETF Date: August 2013 Mailbox: fgont@si6networks.com Pages: 10 Characters: 20850 Updates: RFC 3971, RFC 4861 I-D Tag: draft-ietf-6man-nd-extension-headers-05.txt URL: http://www.rfc-editor.org/rfc/rfc6980.txt This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective countermeasures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated. This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 08:46:44 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4C2B2C49; Wed, 14 Aug 2013 08:46:44 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 28D8D27E4; Wed, 14 Aug 2013 08:46:43 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.89,875,1367996400"; d="asc'?scan'208";a="38333413" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx2-out.netapp.com with ESMTP; 14 Aug 2013 01:46:43 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Wed, 14 Aug 2013 01:46:43 -0700 From: "Eggert, Lars" To: Lawrence Stewart Subject: Re: TCP Initial Window 10 MFC (was: Re: svn commit: r252789 - stable/9/sys/netinet) Thread-Topic: TCP Initial Window 10 MFC (was: Re: svn commit: r252789 - stable/9/sys/netinet) Thread-Index: AQHOmJho/QNBxT9cUU6iUzIYTWLwbZmU2b+A Date: Wed, 14 Aug 2013 08:46:42 +0000 Message-ID: <918804B0-BED8-4E49-9D70-01DDA6F257B3@netapp.com> References: <201307051458.r65EwObo066269@svn.freebsd.org> <520AED2F.4050001@freebsd.org> In-Reply-To: <520AED2F.4050001@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_B3745D06-2FF8-4084-97F8-CD8A376D9148"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Andre Oppermann , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 08:46:44 -0000 --Apple-Mail=_B3745D06-2FF8-4084-97F8-CD8A376D9148 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On Aug 14, 2013, at 10:36, Lawrence Stewart = wrote: > I don't think this change should have been MFCed, at least not in its > current form. FYI, Google's own data as presented in the HTTPBIS working group of the = recent Berlin IETF shows that 10 is too high for ~25% of their web = connections: see slide 2 of = http://www.ietf.org/proceedings/87/slides/slides-87-httpbis-5.pdf (That slide shows a CDF of CWND values the server used at the end of a = web transaction.) Lars --Apple-Mail=_B3745D06-2FF8-4084-97F8-CD8A376D9148 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQCVAwUBUgtD8tZcnpRveo1xAQLU+QP8ClvDtTvHbaxmGUVnGCy66QhS73GMJWDR R6JdOsSoYTcv4ce1pubms8Vd6DMg13YWIHuQkuUF7zzYxYEwBibIV5pGFpW5QGs5 wEELdDttxEADY+oEuCPVCqG4XD5cmsLIRNjiZgUSiHUcjvmhUX2g5Hpis7QvOhKv eJWof98+FkM= =Amuz -----END PGP SIGNATURE----- --Apple-Mail=_B3745D06-2FF8-4084-97F8-CD8A376D9148-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 09:27:19 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 275D95D8; Wed, 14 Aug 2013 09:27:19 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id DDCE82A3B; Wed, 14 Aug 2013 09:27:18 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 95AFE7E81E; Wed, 14 Aug 2013 19:27:15 +1000 (EST) Message-ID: <520B4D73.90408@freebsd.org> Date: Wed, 14 Aug 2013 19:27:15 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130801 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: TCP Initial Window 10 MFC References: <201307051458.r65EwObo066269@svn.freebsd.org> <520AED2F.4050001@freebsd.org> <918804B0-BED8-4E49-9D70-01DDA6F257B3@netapp.com> In-Reply-To: <918804B0-BED8-4E49-9D70-01DDA6F257B3@netapp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: Andre Oppermann , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 09:27:19 -0000 Hi Lars, On 08/14/13 18:46, Eggert, Lars wrote: > Hi, > > On Aug 14, 2013, at 10:36, Lawrence Stewart wrote: >> I don't think this change should have been MFCed, at least not in its >> current form. > > FYI, Google's own data as presented in the HTTPBIS working group of the recent Berlin IETF shows that 10 is too high for ~25% of their web connections: see slide 2 of http://www.ietf.org/proceedings/87/slides/slides-87-httpbis-5.pdf > > (That slide shows a CDF of CWND values the server used at the end of a web transaction.) Thanks for the pointer - very interesting. Do you recall if they said how many flows made up the CDF? Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 10:08:57 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2016E685 for ; Wed, 14 Aug 2013 10:08:57 +0000 (UTC) (envelope-from talayeh.asadi@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E88CA2D71 for ; Wed, 14 Aug 2013 10:08:56 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id s9so11782758iec.6 for ; Wed, 14 Aug 2013 03:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:from:date:message-id:subject:to :content-type; bh=iSmlPNvrBsxFgDCLyaG0ad0xKO+pfoFmpn/D8clVbp4=; b=rvtpmMeEYML9Kv48YTahNbIfWhDG9ELIKASBC/OTqcYvZ1KxD6VqpWFWhxVsdvGat4 oBKW6Ud6+Vwgo3qYngwxk1yGQOj09u+Zl1sVf0Ca2DYGpSVy9S0nnXGynRoDT1Kh9IoN ospLvUa6OGaopDF3hPn2CpeznzeeqPxsFJwUc7NoV6EXSI35jRa0Q3ZrYvRGnu2Usu4p Zc28CDlhTc42mVnTaPxS/Yh1HXELRQ9TpqoXjW95Xq8JhmFuqg3Nfku9uX/3cQ2h5C0h OX6rRTzUwn2zuVDy6lUEh35CEScsJ618U1uXO9CoadWICfscsnxk2xtmHaCBFmawvZI3 pCCQ== X-Received: by 10.50.131.137 with SMTP id om9mr5441926igb.55.1376474936509; Wed, 14 Aug 2013 03:08:56 -0700 (PDT) MIME-Version: 1.0 Sender: talayeh.asadi@gmail.com Received: by 10.42.153.8 with HTTP; Wed, 14 Aug 2013 03:08:35 -0700 (PDT) From: takCoder Date: Wed, 14 Aug 2013 14:38:35 +0430 X-Google-Sender-Auth: 3OVVUcLb6DGrbWXf7a6OSQSuL3k Message-ID: Subject: telnet authentication using RADIUS To: Freebsd-net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: tak.official@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 10:08:57 -0000 hi all, I need to apply radius authentication for my remote connections. For ssh, I have no problems, as I use pam.d/sshd file to add pam_radius.so entry.. but for telnet I've faced a problem.. as I have seen, for non-SRA telnet connections, telnet authentication will be done via pam.d/login rather than pam.d/telnetd.. and this depends on telnet client as well rather than just my server.. I need it to always apply pam.d/telnetd file for all telnet authentications, so i can separate my remote authentication policies from local ones.. am I right with the facts I said above about telnet? Do you know of any tip or trick on this?? any ideas are really appreciated.. Thank you :) Best Regards, t.a.k From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 10:24:37 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 240239AD; Wed, 14 Aug 2013 10:24:37 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 9E5B12E52; Wed, 14 Aug 2013 10:24:36 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B9E617300A; Wed, 14 Aug 2013 12:21:09 +0200 (CEST) Date: Wed, 14 Aug 2013 12:21:09 +0200 From: Luigi Rizzo To: Lawrence Stewart Subject: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) Message-ID: <20130814102109.GA63246@onelab2.iet.unipi.it> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <520B3056.1000804@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 10:24:37 -0000 On Wed, Aug 14, 2013 at 05:23:02PM +1000, Lawrence Stewart wrote: > On 08/14/13 16:33, Julian Elischer wrote: > > On 8/14/13 11:39 AM, Lawrence Stewart wrote: > >> On 08/14/13 03:29, Julian Elischer wrote: > >>> I have been tracking down a performance embarrassment on AMAZON EC2 and > >>> have found it I think. > >> Let us please avoid conflating performance with throughput. The > >> behaviour you go on to describe as a performance embarrassment is > >> actually a throughput difference, and the FreeBSD behaviour you're > >> describing is essentially sacrificing throughput and CPU cycles for > >> lower latency. That may not be a trade-off you like, but it is an > >> important factor in this discussion. ... > Sure, there's nothing wrong with holding throughput up as a key > performance metric for your use case. > > I'm just trying to pre-empt a discussion that focuses on one metric and > fails to consider the bigger picture. ... > > I could see no latency reversion. > > You wouldn't because it would be practically invisible in the sorts of > tests/measurements you're doing. Our good friends over at HRT on the > other hand would be far more likely to care about latency on the order > of microseconds. Again, the use case matters a lot. ... > > so, does "Software LRO" mean that LRO on hte NIC should be ON or OFF to > > see this? > > I think (check the driver code in question as I'm not sure) that if you > "ifconfig lro" and the driver has hardware support or has been made > aware of our software implementation, it should DTRT. The "lower throughput than linux" that julian was seeing is either because of a slow (CPU-bound) sender or slow receiver. Given that the FreeBSD tx path is quite expensive (redoing route and arp lookups on every packet, etc.) I highly suspect the sender side is at fault. Ack coalescing, LRO, GRO are limited to the set of packets that you receive in the same batch, which in turn is upper bounded by the interrupt moderation delay. Apart from simple benchmarks with only a few flows, it is very hard that ack/lro/gro can coalesce more than a few segments for the same flow. But the real fix is in tcp_output. In fact, it has never been the case that an ack (single or coalesced) triggers an immediate transmission in the output path. We had this in the past (Silly Window Syndrome) and there is code that avoids sending less than 1-mtu under appropriate conditions (there is more data to push out anyways, no NODELAY, there are outstanding acks, the window can open further). In all these cases there is no reasonable way to experience the difference in terms of latency. If one really cares, e.g. the High Speed Trading example, this is a non issue because any reasonable person would run with TCP_NODELAY (and possibly disable interrupt moderation), and optimize for latency even on a per flow basis. In terms of coding effort, i suspect that by replacing the 1-mtu limit (t_maxseg i believe is the variable that we use in the SWS avoidance code) with 1-max-tso-segment we can probably achieve good results with little programming effort. Then the problem remains that we should keep a copy of route and arp information in the socket instead of redoing the lookups on every single transmission, as they consume some 25% of the time of a sendto(), and probably even more when it comes to large tcp segments, sendfile() and the like. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 11:47:22 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E6F2A376; Wed, 14 Aug 2013 11:47:22 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id A53432345; Wed, 14 Aug 2013 11:47:21 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:e82a:4e48:57ff:b6e3]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id C25744AC1C; Wed, 14 Aug 2013 15:47:19 +0400 (MSK) Date: Wed, 14 Aug 2013 15:47:13 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <587579055.20130814154713@serebryakov.spb.ru> To: Luigi Rizzo Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) In-Reply-To: <20130814102109.GA63246@onelab2.iet.unipi.it> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Lawrence Stewart , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 11:47:23 -0000 Hello, Luigi. You wrote 14 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2013 =D0=B3., 14:21= :09: LR> Then the problem remains that we should keep a copy of route and LR> arp information in the socket instead of redoing the lookups on LR> every single transmission, as they consume some 25% of the time of LR> a sendto(), and probably even more when it comes to large tcp LR> segments, sendfile() and the like. And we should invalidate this info on ARP/route changes, or connection will be lost in such cases, am I right?.. So, on each such event code should look into all sockets and check, if routing/ARP information is still valid for them. Or we should store lists of sockets in routing and ARP tables... I don't know, what is worse. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 12:01:16 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2A008D14; Wed, 14 Aug 2013 12:01:16 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id DEB7924A0; Wed, 14 Aug 2013 12:01:15 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6F3657300A; Wed, 14 Aug 2013 14:05:51 +0200 (CEST) Date: Wed, 14 Aug 2013 14:05:51 +0200 From: Luigi Rizzo To: Lev Serebryakov Subject: route/arp lifetime (Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)) Message-ID: <20130814120551.GA64260@onelab2.iet.unipi.it> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <587579055.20130814154713@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <587579055.20130814154713@serebryakov.spb.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Lawrence Stewart , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 12:01:16 -0000 On Wed, Aug 14, 2013 at 03:47:13PM +0400, Lev Serebryakov wrote: > Hello, Luigi. > You wrote 14 ?????????????? 2013 ??., 14:21:09: > > LR> Then the problem remains that we should keep a copy of route and > LR> arp information in the socket instead of redoing the lookups on > LR> every single transmission, as they consume some 25% of the time of > LR> a sendto(), and probably even more when it comes to large tcp > LR> segments, sendfile() and the like. > And we should invalidate this info on ARP/route changes, or connection > will be lost in such cases, am I right?.. So, on each such event code > should look into all sockets and check, if routing/ARP information is still > valid for them. Or we should store lists of sockets in routing and ARP > tables... I don't know, what is worse. I think we should start by acknowledging that routing and ARP information is inherently stale, and changes unfrequently. So it is not a disaster if we have incorrect information for some short amount of time (milliseconds) because in the end the remote party that decides to change it and inform us may take much longer than that to distribute the update. Considering that each lookup takes between 100..300ns if you are lucky (not many misses, relatively empty table etc.), one could reasonably do the lookup at most once per millisecond or so (just reading 'ticks', no need for a nanotime() if you have a slow clock), or whenever we get an error related to the socket, either in the forward path (e.g. ifp points to an interface that is down) or in the reverse path (e.g. a dupack because we sent a packet to the wrong place). cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 12:03:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E5DAEE4F for ; Wed, 14 Aug 2013 12:03:23 +0000 (UTC) (envelope-from vsevolod@FreeBSD.org) Received: from n.highsecure.ru (n.highsecure.ru [178.32.219.154]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF98224C8 for ; Wed, 14 Aug 2013 12:03:23 +0000 (UTC) Received: from medway.cl.cam.ac.uk (medway.cl.cam.ac.uk [128.232.64.24]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by n.highsecure.ru (Postfix) with ESMTPSA id 186FA2201F3; Wed, 14 Aug 2013 13:02:08 +0100 (BST) Message-ID: <520B7201.4060507@FreeBSD.org> Date: Wed, 14 Aug 2013 13:03:13 +0100 From: Vsevolod Stakhov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: ng_ipacct locking rework Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Roman V. Palagin" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 12:03:24 -0000 Hello, I've reworked the locking model of the ng_ipacct module (ports/net-mgmt/ng_ipacct) for better parallel access support. I did the following: - convert locking from a global mutex to hash bucket level locks; - convert a mutex to rmlock (as ip accounting data is mostly read from the hash from my observations). I appreciate if somebody could review/test this patch and thus I can commit it to the port afterwards. The patches themselves are here: http://highsecure.ru/patch-ng_ipacct.c http://highsecure.ru/patch-ng_ipacct_hash.h Or for comfortable viewing are mirrored on gist: https://gist.github.com/vstakhov/6223170 -- Vsevolod Stakhov From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 12:17:18 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3377D459; Wed, 14 Aug 2013 12:17:18 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E9C73258F; Wed, 14 Aug 2013 12:17:13 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=dhcp170-36-red.yandex.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1V9a3m-000Pmr-7T; Wed, 14 Aug 2013 16:20:18 +0400 Message-ID: <520B74DD.1060102@ipfw.ru> Date: Wed, 14 Aug 2013 16:15:25 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130418 Thunderbird/17.0.5 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: route/arp lifetime (Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)) References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <587579055.20130814154713@serebryakov.spb.ru> <20130814120551.GA64260@onelab2.iet.unipi.it> In-Reply-To: <20130814120551.GA64260@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , Lev Serebryakov , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 12:17:18 -0000 On 14.08.2013 16:05, Luigi Rizzo wrote: > On Wed, Aug 14, 2013 at 03:47:13PM +0400, Lev Serebryakov wrote: >> Hello, Luigi. >> You wrote 14 ?????????????? 2013 ??., 14:21:09: >> >> LR> Then the problem remains that we should keep a copy of route and >> LR> arp information in the socket instead of redoing the lookups on >> LR> every single transmission, as they consume some 25% of the time of >> LR> a sendto(), and probably even more when it comes to large tcp >> LR> segments, sendfile() and the like. >> And we should invalidate this info on ARP/route changes, or connection >> will be lost in such cases, am I right?.. So, on each such event code >> should look into all sockets and check, if routing/ARP information is still >> valid for them. Or we should store lists of sockets in routing and ARP >> tables... I don't know, what is worse. > I think we should start by acknowledging that routing and ARP > information is inherently stale, and changes unfrequently. > So it is not a disaster if we have incorrect information for some > short amount of time (milliseconds) because in the end the remote > party that decides to change it and inform us may take much longer > than that to distribute the update. You can save rte&arp, however doing this gives you perfect chance to crash your kernel if egress interface is destroyed (like vlan or ng or tun). > > > Considering that each lookup takes between 100..300ns if you are > lucky (not many misses, relatively empty table etc.), one could > reasonably do the lookup at most once per millisecond or so (just > reading 'ticks', no need for a nanotime() if you have a slow clock), > or whenever we get an error related to the socket, either in the > forward path (e.g. ifp points to an interface that is down) or in > the reverse path (e.g. a dupack because we sent a packet to the > wrong place). This sounds like "Hey, the kernel lookup is slow (which is true), let's make a hack and don't bother lookups". This approach gives us mtx-locked rte refcounts which are used (misused) in many places making things worse and decreasing the ability to fix the things up.. > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://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 Aug 14 12:35:49 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CFBF2C7E; Wed, 14 Aug 2013 12:35:49 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 55D8D26AA; Wed, 14 Aug 2013 12:35:49 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E547E7300A; Wed, 14 Aug 2013 14:40:24 +0200 (CEST) Date: Wed, 14 Aug 2013 14:40:24 +0200 From: Luigi Rizzo To: "Alexander V. Chernikov" Subject: Re: route/arp lifetime (Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)) Message-ID: <20130814124024.GA64548@onelab2.iet.unipi.it> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <587579055.20130814154713@serebryakov.spb.ru> <20130814120551.GA64260@onelab2.iet.unipi.it> <520B74DD.1060102@ipfw.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <520B74DD.1060102@ipfw.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Lawrence Stewart , Lev Serebryakov , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 12:35:50 -0000 On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote: > On 14.08.2013 16:05, Luigi Rizzo wrote: > > On Wed, Aug 14, 2013 at 03:47:13PM +0400, Lev Serebryakov wrote: > >> Hello, Luigi. > >> You wrote 14 ?????????????? 2013 ??., 14:21:09: > >> > >> LR> Then the problem remains that we should keep a copy of route and > >> LR> arp information in the socket instead of redoing the lookups on > >> LR> every single transmission, as they consume some 25% of the time of > >> LR> a sendto(), and probably even more when it comes to large tcp > >> LR> segments, sendfile() and the like. > >> And we should invalidate this info on ARP/route changes, or connection > >> will be lost in such cases, am I right?.. So, on each such event code > >> should look into all sockets and check, if routing/ARP information is still > >> valid for them. Or we should store lists of sockets in routing and ARP > >> tables... I don't know, what is worse. > > I think we should start by acknowledging that routing and ARP > > information is inherently stale, and changes unfrequently. > > So it is not a disaster if we have incorrect information for some > > short amount of time (milliseconds) because in the end the remote > > party that decides to change it and inform us may take much longer > > than that to distribute the update. > You can save rte&arp, however doing this > gives you perfect chance to crash your kernel if egress interface is > destroyed (like vlan or ng or tun). I hope I learned not to follow a stale ifp pointer :) anyways ARP is really just the mac address so there is no dandling pointer issue. For the ifp associated to the route, i do not see a huge problem in marking the route/ifp as zombie and destroy it when the last reference goes away. Not that the current way is any better -- you need to lock/unlock the rte while you do the lookup, and hold a refcount to the ifp until the packet is queued. So how does my suggestion make things worse ? cheers luigi > > > > > > Considering that each lookup takes between 100..300ns if you are > > lucky (not many misses, relatively empty table etc.), one could > > reasonably do the lookup at most once per millisecond or so (just > > reading 'ticks', no need for a nanotime() if you have a slow clock), > > or whenever we get an error related to the socket, either in the > > forward path (e.g. ifp points to an interface that is down) or in > > the reverse path (e.g. a dupack because we sent a packet to the > > wrong place). > This sounds like "Hey, the kernel lookup is slow (which is true), let's > make a hack and don't bother lookups". > This approach gives us mtx-locked rte refcounts which are used (misused) > in many places making things worse and decreasing the ability to fix the > things up.. > > > > cheers > > luigi > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://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 Aug 14 13:02:54 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3E5E3B64; Wed, 14 Aug 2013 13:02:54 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F1D99298C; Wed, 14 Aug 2013 13:02:52 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=dhcp170-36-red.yandex.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1V9aly-000149-VA; Wed, 14 Aug 2013 17:05:59 +0400 Message-ID: <520B7F91.2080209@ipfw.ru> Date: Wed, 14 Aug 2013 17:01:05 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130418 Thunderbird/17.0.5 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: route/arp lifetime (Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)) References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <587579055.20130814154713@serebryakov.spb.ru> <20130814120551.GA64260@onelab2.iet.unipi.it> <520B74DD.1060102@ipfw.ru> <20130814124024.GA64548@onelab2.iet.unipi.it> In-Reply-To: <20130814124024.GA64548@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , Lev Serebryakov , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 13:02:54 -0000 On 14.08.2013 16:40, Luigi Rizzo wrote: > On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote: >> On 14.08.2013 16:05, Luigi Rizzo wrote: >>> On Wed, Aug 14, 2013 at 03:47:13PM +0400, Lev Serebryakov wrote: >>>> Hello, Luigi. >>>> You wrote 14 ?????????????? 2013 ??., 14:21:09: >>>> >>>> LR> Then the problem remains that we should keep a copy of route and >>>> LR> arp information in the socket instead of redoing the lookups on >>>> LR> every single transmission, as they consume some 25% of the time of >>>> LR> a sendto(), and probably even more when it comes to large tcp >>>> LR> segments, sendfile() and the like. >>>> And we should invalidate this info on ARP/route changes, or connection >>>> will be lost in such cases, am I right?.. So, on each such event code >>>> should look into all sockets and check, if routing/ARP information is still >>>> valid for them. Or we should store lists of sockets in routing and ARP >>>> tables... I don't know, what is worse. >>> I think we should start by acknowledging that routing and ARP >>> information is inherently stale, and changes unfrequently. >>> So it is not a disaster if we have incorrect information for some >>> short amount of time (milliseconds) because in the end the remote >>> party that decides to change it and inform us may take much longer >>> than that to distribute the update. >> You can save rte&arp, however doing this >> gives you perfect chance to crash your kernel if egress interface is >> destroyed (like vlan or ng or tun). > I hope I learned not to follow a stale ifp pointer :) Well, currently we have no locks (or other means) to ensure all other cores has "current" pointer to ifp or its fields (or am I wrong?) > anyways ARP is really just the mac address so there is no > dandling pointer issue. > > For the ifp associated to the route, > i do not see a huge problem in marking the route/ifp as > zombie and destroy it when the last reference goes away. Yes, but references requires some synchronization primitives. One possible solution is using pcpu counters, but it does not play well on !amd64. > > Not that the current way is any better -- you need to lock/unlock > the rte while you do the lookup, and hold a refcount to the ifp > until the packet is queued. So how does my suggestion make > things worse ? > > cheers > luigi > > >>> >>> Considering that each lookup takes between 100..300ns if you are >>> lucky (not many misses, relatively empty table etc.), one could >>> reasonably do the lookup at most once per millisecond or so (just >>> reading 'ticks', no need for a nanotime() if you have a slow clock), >>> or whenever we get an error related to the socket, either in the >>> forward path (e.g. ifp points to an interface that is down) or in >>> the reverse path (e.g. a dupack because we sent a packet to the >>> wrong place). >> This sounds like "Hey, the kernel lookup is slow (which is true), let's >> make a hack and don't bother lookups". >> This approach gives us mtx-locked rte refcounts which are used (misused) >> in many places making things worse and decreasing the ability to fix the >> things up.. >>> cheers >>> luigi >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://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 Aug 14 13:40:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 25DDE577 for ; Wed, 14 Aug 2013 13:40:27 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id E43772B9B for ; Wed, 14 Aug 2013 13:40:24 +0000 (UTC) Received: from [192.168.1.54] (staff-ns50-3.as25178.net [212.9.98.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 3cFWs3140pzwt for ; Wed, 14 Aug 2013 14:31:03 +0100 (BST) Message-ID: <520B8694.1050407@rewt.org.uk> Date: Wed, 14 Aug 2013 14:31:00 +0100 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Updating route MTU when interface changes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 13:40:27 -0000 Hi guys, I noticed this some years ago but I just checked and its still there - when the mtu of an interface is changed, any routes (eg connected route) using that interface aren't updated until the interface is shut/unshut - is this by design or is it an oversight? Having to down/up remote machine interfaces that are potentially forwarding traffic just to change the mtu seems silly. Ta, Joe From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 13:55:38 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 68EE4C52; Wed, 14 Aug 2013 13:55:38 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id DFBDA2C87; Wed, 14 Aug 2013 13:55:37 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 82DA07300A; Wed, 14 Aug 2013 16:00:13 +0200 (CEST) Date: Wed, 14 Aug 2013 16:00:13 +0200 From: Luigi Rizzo To: "Alexander V. Chernikov" Subject: Re: route/arp lifetime (Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)) Message-ID: <20130814140013.GA65049@onelab2.iet.unipi.it> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <587579055.20130814154713@serebryakov.spb.ru> <20130814120551.GA64260@onelab2.iet.unipi.it> <520B74DD.1060102@ipfw.ru> <20130814124024.GA64548@onelab2.iet.unipi.it> <520B7F91.2080209@ipfw.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <520B7F91.2080209@ipfw.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Lawrence Stewart , Lev Serebryakov , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 13:55:38 -0000 On Wed, Aug 14, 2013 at 05:01:05PM +0400, Alexander V. Chernikov wrote: > On 14.08.2013 16:40, Luigi Rizzo wrote: ... > >> You can save rte&arp, however doing this > >> gives you perfect chance to crash your kernel if egress interface is > >> destroyed (like vlan or ng or tun). > > I hope I learned not to follow a stale ifp pointer :) > Well, currently we have no locks (or other means) to ensure all other > cores has "current" pointer to ifp or its fields (or am I wrong?) This i don't know -- but in case, we should fix the race anyways (another timescale, but still dangerous). > > anyways ARP is really just the mac address so there is no > > dandling pointer issue. > > > > For the ifp associated to the route, > > i do not see a huge problem in marking the route/ifp as > > zombie and destroy it when the last reference goes away. > Yes, but references requires some synchronization primitives. One Again, we should protect against ifp destruction anyways. Surely we should try and make the protection mechanism cheap (in my proposal, going through the refcount once per millisecond instead of every single packet; there might be better ways, and i am all ears on that); surely, we cannot dismiss something because "we run without seatbelts now so anything else is more expensive". We had a related discussion regarding races in interfaces between the datapath (if_transmit() and *_rxeof() ) and the control path (ioctls, watchdog etc.). The reason I am raising this issue is because i want to fix the races that emerged when we moved to SMP, not because I want to "make hacks" and cut corners in unsafe ways. cheers luigi > possible solution is using pcpu counters, but it does not play well on > !amd64. > > > > Not that the current way is any better -- you need to lock/unlock > > the rte while you do the lookup, and hold a refcount to the ifp > > until the packet is queued. So how does my suggestion make > > things worse ? > > > > cheers > > luigi > > > > > >>> > >>> Considering that each lookup takes between 100..300ns if you are > >>> lucky (not many misses, relatively empty table etc.), one could > >>> reasonably do the lookup at most once per millisecond or so (just > >>> reading 'ticks', no need for a nanotime() if you have a slow clock), > >>> or whenever we get an error related to the socket, either in the > >>> forward path (e.g. ifp points to an interface that is down) or in > >>> the reverse path (e.g. a dupack because we sent a packet to the > >>> wrong place). > >> This sounds like "Hey, the kernel lookup is slow (which is true), let's > >> make a hack and don't bother lookups". > >> This approach gives us mtx-locked rte refcounts which are used (misused) > >> in many places making things worse and decreasing the ability to fix the > >> things up.. > >>> cheers > >>> luigi > >>> _______________________________________________ > >>> freebsd-net@freebsd.org mailing list > >>> http://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 Aug 14 15:40:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 871EF14B; Wed, 14 Aug 2013 15:40:18 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C47BE22F1; Wed, 14 Aug 2013 15:40:17 +0000 (UTC) Received: from x23.lan (89.164.9.9) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 14 Aug 2013 17:40:15 +0200 From: Marko Zec To: Subject: Re: route/arp lifetime (Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)) Date: Wed, 14 Aug 2013 17:40:28 +0200 User-Agent: KMail/1.9.10 References: <520A6D07.5080106@freebsd.org> <520B74DD.1060102@ipfw.ru> <20130814124024.GA64548@onelab2.iet.unipi.it> In-Reply-To: <20130814124024.GA64548@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201308141740.28779.zec@fer.hr> X-Originating-IP: [89.164.9.9] Cc: Lawrence Stewart , Lev Serebryakov , Luigi Rizzo , "Alexander V. Chernikov" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 15:40:18 -0000 On Wednesday 14 August 2013 14:40:24 Luigi Rizzo wrote: > On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote: > > On 14.08.2013 16:05, Luigi Rizzo wrote: > > > On Wed, Aug 14, 2013 at 03:47:13PM +0400, Lev Serebryakov wrote: > > >> Hello, Luigi. > > >> You wrote 14 ?????????????? 2013 ??., 14:21:09: > > >> > > >> LR> Then the problem remains that we should keep a copy of route and > > >> LR> arp information in the socket instead of redoing the lookups on > > >> LR> every single transmission, as they consume some 25% of the time > > >> of LR> a sendto(), and probably even more when it comes to large tcp > > >> LR> segments, sendfile() and the like. > > >> And we should invalidate this info on ARP/route changes, or > > >> connection will be lost in such cases, am I right?.. So, on each > > >> such event code should look into all sockets and check, if > > >> routing/ARP information is still valid for them. Or we should store > > >> lists of sockets in routing and ARP tables... I don't know, what is > > >> worse. > > > > > > I think we should start by acknowledging that routing and ARP > > > information is inherently stale, and changes unfrequently. > > > So it is not a disaster if we have incorrect information for some > > > short amount of time (milliseconds) because in the end the remote > > > party that decides to change it and inform us may take much longer > > > than that to distribute the update. > > > > You can save rte&arp, however doing this > > gives you perfect chance to crash your kernel if egress interface is > > destroyed (like vlan or ng or tun). > > I hope I learned not to follow a stale ifp pointer :) > anyways ARP is really just the mac address so there is no > dandling pointer issue. > > For the ifp associated to the route, > i do not see a huge problem in marking the route/ifp as > zombie and destroy it when the last reference goes away. FWIW, apparently we already have that infrastrucure in place - if_rele() calls if_free_internal() only when the last reference to the ifnet is dropped, so with little care this should be usable for caching ifp pointers w/o fears for kernel crashes mentioned above. Marko > Not that the current way is any better -- you need to lock/unlock > the rte while you do the lookup, and hold a refcount to the ifp > until the packet is queued. So how does my suggestion make > things worse ? > > cheers > luigi > > > > Considering that each lookup takes between 100..300ns if you are > > > lucky (not many misses, relatively empty table etc.), one could > > > reasonably do the lookup at most once per millisecond or so (just > > > reading 'ticks', no need for a nanotime() if you have a slow clock), > > > or whenever we get an error related to the socket, either in the > > > forward path (e.g. ifp points to an interface that is down) or in > > > the reverse path (e.g. a dupack because we sent a packet to the > > > wrong place). > > > > This sounds like "Hey, the kernel lookup is slow (which is true), let's > > make a hack and don't bother lookups". > > This approach gives us mtx-locked rte refcounts which are used > > (misused) in many places making things worse and decreasing the ability > > to fix the things up.. > > > > > cheers > > > luigi > > > _______________________________________________ > > > freebsd-net@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to > > > "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://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 Aug 14 15:44:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 821313D8; Wed, 14 Aug 2013 15:44:19 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 3FC6F2346; Wed, 14 Aug 2013 15:44:19 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E11757300A; Wed, 14 Aug 2013 17:48:53 +0200 (CEST) Date: Wed, 14 Aug 2013 17:48:53 +0200 From: Luigi Rizzo To: Marko Zec Subject: Re: route/arp lifetime (Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)) Message-ID: <20130814154853.GA66341@onelab2.iet.unipi.it> References: <520A6D07.5080106@freebsd.org> <520B74DD.1060102@ipfw.ru> <20130814124024.GA64548@onelab2.iet.unipi.it> <201308141740.28779.zec@fer.hr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201308141740.28779.zec@fer.hr> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org, Lev Serebryakov , FreeBSD Net , "Alexander V. Chernikov" , Lawrence Stewart X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 15:44:19 -0000 On Wed, Aug 14, 2013 at 05:40:28PM +0200, Marko Zec wrote: > On Wednesday 14 August 2013 14:40:24 Luigi Rizzo wrote: > > On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote: ... > FWIW, apparently we already have that infrastrucure in place - if_rele() > calls if_free_internal() only when the last reference to the ifnet is > dropped, so with little care this should be usable for caching ifp pointers > w/o fears for kernel crashes mentioned above. maybe Alexander was referring to holding references to the rte entries returned as a result of the lookup. The rte holds a reference to the ifp. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 16:05:12 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E040396B; Wed, 14 Aug 2013 16:05:11 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDE6E245C; Wed, 14 Aug 2013 16:05:11 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r7EG56r7018504 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Aug 2013 09:05:09 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <520BAAAC.8070707@freebsd.org> Date: Thu, 15 Aug 2013 00:05:00 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Lawrence Stewart Subject: Re: TSO and FreeBSD vs Linux References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> In-Reply-To: <520B24A0.4000706@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 16:05:12 -0000 On 8/14/13 2:33 PM, Julian Elischer wrote: > On 8/14/13 11:39 AM, Lawrence Stewart wrote: > There's a thing controlled by ethtool called GRO (generic receive >> offload) which appears to be enabled by default on at least Ubuntu >> and I >> guess other Linux's too. It's responsible for aggregating ACKs and >> data >> to batch them up the stack if the driver doesn't provide a hardware >> offload implementation. Try rerunning your experiments with the ACK >> batching disabled on the Linux host to get an additional comparison >> point. > I will try that as soon as I get back to the machines in question. turning on and off GRO seems to make no difference, either at the overall throughput level or at the low level packet-by-packet level (according to tcptrace). >>> for two examples look at: >>> >>> >>> http://www.freebsd.org/~julian/LvsF-tcp-start.tiff >>> and >>> http://www.freebsd.org/~julian/LvsF-tcp.tiff >>> >>> in each case, we can see FreeBSD on the left and Linux on the right. >>> >>> The first case shows the case as the sessions start, and the >>> second case >>> shows >>> some distance later (when the sequence numbers wrap around.. no >>> particular >>> reason to use that, it was just fun to see). >>> In both cases you can see that each Linux packet (white)(once they >>> have got >>> going) is responding to multiple bumps in the send window sequence >>> number (green and yellow lines) (representing the arrival of >>> several ACKs) >>> while FreeBSD produces a whole bunch of smaller packets, slavishly >>> following >>> exactly the size of each incoming ack.. This gives us quite a >>> performance debt. >> Again, please s/performance/what-you-really-mean/ here. > ok, In my tests this makes FreeBSD data transfers much slower, by as > much as 60%. >> >>> Notice that this behaviour in Linux seems to be modal.. it seems to >>> 'switch on' a little bit >>> into the 'starting' trace. >>> >>> In addition, you can see also that Linux gets going faster even in >>> the >>> beginning where >>> TSO isn't in play, by sending a lot more packets up-front. (of course >>> the wisdom of this >>> can be argued). >> They switched to using an initial window of 10 segments some time ago. >> FreeBSD starts with 3 or more recently, 10 if you're running recent >> 9-STABLE or 10-CURRENT. > I tried setting initial values as shown: > net.inet.tcp.local_slowstart_flightsize: 10 > net.inet.tcp.slowstart_flightsize: 10 > it didn't seem to make too much difference but I will redo the test. > >> >>> Has anyone done any work on aggregating ACKs, or delaying >>> responding to >>> them? >> As noted by Navdeep, we already have the code to aggregate ACKs in our >> software LRO implementation. The bigger problem is that appropriate >> byte >> counting places a default 2*MSS limit on the amount of ACKed data the >> window can grow by i.e. if an ACK for 64k of data comes up the stack, >> we'll grow the window by 2 segments worth of data in response. That >> needs to be addressed - we could send the ACK count up with the >> aggregated single ACK or just ignore abc_l_var when LRO is in use >> for a >> connection. > so, does "Software LRO" mean that LRO on hte NIC should be ON or OFF > to see this? > > >> >> Cheers, >> Lawrence >> >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://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 Aug 14 16:44:44 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A318D3D2 for ; Wed, 14 Aug 2013 16:44:44 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE3F826D9 for ; Wed, 14 Aug 2013 16:44:43 +0000 (UTC) Received: (qmail 21905 invoked from network); 14 Aug 2013 17:28:57 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Aug 2013 17:28:57 -0000 Message-ID: <520BB3F0.4020506@freebsd.org> Date: Wed, 14 Aug 2013 18:44:32 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Lawrence Stewart Subject: Re: TCP Initial Window 10 MFC References: <201307051458.r65EwObo066269@svn.freebsd.org> <520AED2F.4050001@freebsd.org> In-Reply-To: <520AED2F.4050001@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 16:44:44 -0000 On 14.08.2013 04:36, Lawrence Stewart wrote: > Hi Andre, > > [RE team is BCCed so they're aware of this discussion] > > On 07/06/13 00:58, Andre Oppermann wrote: >> Author: andre >> Date: Fri Jul 5 14:58:24 2013 >> New Revision: 252789 >> URL: http://svnweb.freebsd.org/changeset/base/252789 >> >> Log: >> MFC r242266: >> >> Increase the initial CWND to 10 segments as defined in IETF TCPM >> draft-ietf-tcpm-initcwnd-05. It explains why the increased initial >> window improves the overall performance of many web services without >> risking congestion collapse. >> >> As long as it remains a draft it is placed under a sysctl marking it >> as experimental: >> net.inet.tcp.experimental.initcwnd10 = 1 >> When it becomes an official RFC soon the sysctl will be changed to >> the RFC number and moved to net.inet.tcp. >> >> This implementation differs from the RFC draft in that it is a bit >> more conservative in the case of packet loss on SYN or SYN|ACK because >> we haven't reduced the default RTO to 1 second yet. Also the restart >> window isn't yet increased as allowed. Both will be adjusted with >> upcoming changes. >> >> Is is enabled by default. In Linux it is enabled since kernel 3.0. > > I haven't been fully alert to FreeBSD happenings this year so apologies > for bringing this up so long after the MFC. > > I don't think this change should have been MFCed, at least not in its > current form. Enabling the switch to IW=10 on a stable branch is > inappropriate IMO. I also think the "net.inet.tcp.experimental" sysctl > branch is poorly named as per the important discussion we had back in > February [1]. I would really prefer we didn't get stuck having to keep > it around by making a stable release with it being present. > > I think this commit should be backed out of stable/9 and more > importantly, 9.2-RELEASE. Backing out the patch isn't really necessary, just flip the switch to off having it revert to the RFC5681 defaults. Those who want it anyway can simply enable it again. IW10 has become RFC6928 (experimental) in April 2013. > As an aside, I am intending to follow up to the Feb discussion with a > patch that implements the basic infrastructure I proposed so that we can > continue that discussion. Again I'm deeply concerned and opposed to giving end users direct control over the IW value. I've had and seen too many cases of totally bogus "tuning" by cranking up random sysctls to insane values and then complaining about FreeBSD being slow compared to Linux (and then ditching FreeBSD). -- Andre > Cheers, > Lawrence > > [1] http://lists.freebsd.org/pipermail/freebsd-net/2013-February/034698.html From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 18:11:06 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CCEEFB81; Wed, 14 Aug 2013 18:11:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13E552BD5; Wed, 14 Aug 2013 18:11:05 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id p58so7978145wes.40 for ; Wed, 14 Aug 2013 11:11:04 -0700 (PDT) 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=uyGC07M3iApI6iriGIStoAJTeTXtdv882n3NxtBCLek=; b=YXjn5n6nr9mPFSWMeSFdL/6ks5yNfT81kzwif/6B1clBGA7ABq2isyHZKU81GioPK4 ncz4bgG+pFcHn/Y3+mmk2FRcKSLmVSgUwYM7zqfDKEZ10pnlQQNr92z2mMpL80IhxIe1 rw1d+YIsf+x+Ciw9toeQiDHRrK3QwkJ/5HKvDxcenHtg9U+6qIKrxFNjQuWS8zMiY9zG x5q2lzWAxpmkVeS6vDZzcm2QrwuYY7i8ncslC35v/Fqm/XShs1ca6QHeKzXsz/Z1qap0 DWj+mV7CU1/OYJXpzHejCaNl85o2oL4Li4/m1JttRBtKK6S1I56aTKv7+B1AkYbF3DUf U9Rw== MIME-Version: 1.0 X-Received: by 10.180.37.164 with SMTP id z4mr2939953wij.30.1376503864231; Wed, 14 Aug 2013 11:11:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Wed, 14 Aug 2013 11:11:04 -0700 (PDT) In-Reply-To: <587579055.20130814154713@serebryakov.spb.ru> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <587579055.20130814154713@serebryakov.spb.ru> Date: Wed, 14 Aug 2013 11:11:04 -0700 X-Google-Sender-Auth: glOPNvNm3PXuhuqP9xyJaiSR_uk Message-ID: Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) From: Adrian Chadd To: Lev Serebryakov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Lawrence Stewart , Luigi Rizzo , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 18:11:06 -0000 On 14 August 2013 04:47, Lev Serebryakov wrote: > And we should invalidate this info on ARP/route changes, or connection > will be lost in such cases, am I right?.. So, on each such event code > should look into all sockets and check, if routing/ARP information is > still > valid for them. Or we should store lists of sockets in routing and ARP > tables... I don't know, what is worse. > .. or per-CPU copies of the ARP table.. ? -adrian From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 19:40:20 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 63A24CC2 for ; Wed, 14 Aug 2013 19:40:20 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D1C4218E for ; Wed, 14 Aug 2013 19:40:20 +0000 (UTC) Received: by mail-ve0-f174.google.com with SMTP id d10so8123066vea.33 for ; Wed, 14 Aug 2013 12:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6zFjB2bwhY+4R1Qst7mshCrVIjcM2qxRAu9JGhFOIhE=; b=DXO+hkLL/EUUfR8iO3wMDfp/FkWwI5YSx64qsMR4kiHymH1Kexb9j3zb/yEQOvcgrk lkkL+FQKsfEDTWhf4pJM5NX9MSEGkd8iXrTjJMHYrx7W5gZpHphOo3gr/M4K5iLIRTs8 2xtq7KEi9uq/XO1DqIFdVbMf6r1o4Nr5YrEoA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6zFjB2bwhY+4R1Qst7mshCrVIjcM2qxRAu9JGhFOIhE=; b=dLJzfZkuCKpH8wmfpGgVgF4hmuwN269e+hYl5P+EujruB1dGRG5HkkiPyHmO/MpBaD geFOtZNw7BErwYZyWdlpNiSIChfpCMRIsSFqmHPglWsUaGW/YFTAGUStsbipiLrTo1K/ Hg3PqEAXHNeElCgJUq2aJ1Zm+GlilmLWuw2hvNTmTnf9gEe4Swa8HIwpj35eOMZQR/s8 fLvSp2eZkUvvdBZsW9pLCzVRh0MyE2cR76NII2nS/NVewdGZ9U2kH5ZECWsU4qqGdbXB zPsYZ84DRoMkW0ORAVEDy/j+KFyWZxE9oRQaXhquLGGfgqhrrJicKiwfCP4L1kV5r//t a15Q== X-Gm-Message-State: ALoCoQmtHPOw68jh4Na0fIQGdrx/WBjqLeF8s5OJs1wev0PRu6rkV+CR/3TPeiai4ZXWkw3RlWNh MIME-Version: 1.0 X-Received: by 10.220.50.10 with SMTP id x10mr599307vcf.86.1376509219229; Wed, 14 Aug 2013 12:40:19 -0700 (PDT) Received: by 10.220.167.74 with HTTP; Wed, 14 Aug 2013 12:40:19 -0700 (PDT) In-Reply-To: References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <587579055.20130814154713@serebryakov.spb.ru> Date: Wed, 14 Aug 2013 12:40:19 -0700 Message-ID: Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) From: Peter Wemm To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Lawrence Stewart , Lev Serebryakov , Luigi Rizzo , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 19:40:20 -0000 On Wed, Aug 14, 2013 at 11:11 AM, Adrian Chadd wrote: > On 14 August 2013 04:47, Lev Serebryakov wrote: > > >> And we should invalidate this info on ARP/route changes, or connection >> will be lost in such cases, am I right?.. So, on each such event code >> should look into all sockets and check, if routing/ARP information is >> still >> valid for them. Or we should store lists of sockets in routing and ARP >> tables... I don't know, what is worse. >> > > .. or per-CPU copies of the ARP table.. ? Local cache at each consumer and check a generation number to see if it needs to be re-validated before using. The obvious problem with this though is that big networks tend to kill your caches. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 19:47:10 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 859A9EDE; Wed, 14 Aug 2013 19:47:10 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57C5D221B; Wed, 14 Aug 2013 19:47:10 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r7EJl0JM019119 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Aug 2013 12:47:02 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <520BDEAE.9000104@freebsd.org> Date: Thu, 15 Aug 2013 03:46:54 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Lawrence Stewart Subject: Re: TSO and FreeBSD vs Linux References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> In-Reply-To: <520B3056.1000804@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 19:47:10 -0000 On 8/14/13 3:23 PM, Lawrence Stewart wrote: > On 08/14/13 16:33, Julian Elischer wrote: > >>> They switched to using an initial window of 10 segments some time ago. >>> FreeBSD starts with 3 or more recently, 10 if you're running recent >>> 9-STABLE or 10-CURRENT. >> I tried setting initial values as shown: >> net.inet.tcp.local_slowstart_flightsize: 10 >> net.inet.tcp.slowstart_flightsize: 10 >> it didn't seem to make too much difference but I will redo the test. > Assuming this is still FreeBSD 8.0 as you mentioned out-of-band, > changing those variables without disabling rfc3390 will have no effect. > > I think (check the driver code in question as I'm not sure) that if you > "ifconfig lro" and the driver has hardware support or has been made > aware of our software implementation, it should DTRT. so I ran on 9.2-beta ( a week or two old) and it had similar problems.. only worse.. 9.2 actually sends multiple packets when is doesn't need to.. http://people.freebsd.org/~julian/fbsd9.png > > Cheers, > Lawrence > > From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 23:27:19 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C6C534BE; Wed, 14 Aug 2013 23:27:19 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 95EBC2ED9; Wed, 14 Aug 2013 23:27:19 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id kq13so191255pab.39 for ; Wed, 14 Aug 2013 16:27:19 -0700 (PDT) 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=AYZQkQ6oR6HAwyKaiUjbVmMJ9SU1nk1QYcpYV7jSmhw=; b=obWxiys6/OLB8HWtdGMu6yQtRCK93YhDxQxd6M1tM/xbAJT7PvQyRoOcu5GZKIvvtT Be2CjMWdZ3MZ0z+GqQ+wZMat+rP+MvDCBM8OpcmlXT8A0EtZalyNat22ojxniYGdYf8o RIOgF04NRah0fj6qDwLt8w72sDq40q7PEww15mdtuOme9/kvtqV3pPPUXuHYXeSOOphA LNixF81lOjJRgCVUL23eF7inWMnraVPpvGi3uwJlNGeEqS8wfUrr5OmQYIGIaf4wDoOy HaVlgwnPzgv7iJWRjlcr/ZZOKoJ7HrvffnrxD3I1YXqtEWOs7bok1MPTNFZeQ6mYBk0T UZ/Q== MIME-Version: 1.0 X-Received: by 10.69.0.168 with SMTP id az8mr12510791pbd.51.1376522839223; Wed, 14 Aug 2013 16:27:19 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.67.14.66 with HTTP; Wed, 14 Aug 2013 16:27:19 -0700 (PDT) In-Reply-To: <520BDEAE.9000104@freebsd.org> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <520BDEAE.9000104@freebsd.org> Date: Wed, 14 Aug 2013 16:27:19 -0700 X-Google-Sender-Auth: Qj9yVZIPQP8pCzvU22GxBP6BuNA Message-ID: Subject: Re: TSO and FreeBSD vs Linux From: Kevin Oberman To: Julian Elischer Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Lawrence Stewart , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 23:27:19 -0000 On Wed, Aug 14, 2013 at 12:46 PM, Julian Elischer wrote: > On 8/14/13 3:23 PM, Lawrence Stewart wrote: > >> On 08/14/13 16:33, Julian Elischer wrote: >> >> They switched to using an initial window of 10 segments some time ago. >>>> FreeBSD starts with 3 or more recently, 10 if you're running recent >>>> 9-STABLE or 10-CURRENT. >>>> >>> I tried setting initial values as shown: >>> net.inet.tcp.local_slowstart_**flightsize: 10 >>> net.inet.tcp.slowstart_**flightsize: 10 >>> it didn't seem to make too much difference but I will redo the test. >>> >> Assuming this is still FreeBSD 8.0 as you mentioned out-of-band, >> changing those variables without disabling rfc3390 will have no effect. >> >> I think (check the driver code in question as I'm not sure) that if you >> "ifconfig lro" and the driver has hardware support or has been made >> aware of our software implementation, it should DTRT. >> > > so I ran on 9.2-beta ( a week or two old) and it had similar problems.. > only worse.. 9.2 actually sends multiple packets when is doesn't need to.. > http://people.freebsd.org/~julian/fbsd9.png > Ack! (Sorry) I could have sworn that this had been fixed. Has it been re-broken? -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 23:27:50 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F2FAE59E; Wed, 14 Aug 2013 23:27:49 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE5BA2EE9; Wed, 14 Aug 2013 23:27:49 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.89,880,1367996400"; d="asc'?scan'208";a="273281248" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx1-out.netapp.com with ESMTP; 14 Aug 2013 16:27:49 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Wed, 14 Aug 2013 16:27:43 -0700 From: "Eggert, Lars" To: Lawrence Stewart Subject: Re: TCP Initial Window 10 MFC Thread-Topic: TCP Initial Window 10 MFC Thread-Index: AQHOmNB79EbS92W2BEyg8HoYjj8dopmVz3QA Date: Wed, 14 Aug 2013 23:27:42 +0000 Message-ID: <4B265DD2-D203-4C36-AB24-ABA00CB021F0@netapp.com> References: <201307051458.r65EwObo066269@svn.freebsd.org> <520AED2F.4050001@freebsd.org> <918804B0-BED8-4E49-9D70-01DDA6F257B3@netapp.com> <520B4D73.90408@freebsd.org> In-Reply-To: <520B4D73.90408@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: multipart/signed; boundary="Apple-Mail=_C98FCEB6-30C3-4D8C-AC79-4FA0DF8A6B42"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Andre Oppermann , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 23:27:50 -0000 --Apple-Mail=_C98FCEB6-30C3-4D8C-AC79-4FA0DF8A6B42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On Aug 14, 2013, at 17:27, Lawrence Stewart wrote: > Do you recall if they said > how many flows made up the CDF? I think "very many" - check out the audio archive or the minutes of the = meeting, it should have the details. Lars --Apple-Mail=_C98FCEB6-30C3-4D8C-AC79-4FA0DF8A6B42 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQCVAwUBUgwSbNZcnpRveo1xAQLUhQQAu8PWruA02itYJQd6viuHpc+2YZZ+nQS/ ekSs/2u1aZbcS56NOgzlxUQF9L1RcvPZcKj581Bi030abJ+oNFjI7qc4rBlJsySL tB5M4wLtaI8kobJWFcqcIBPml0qjKfbnjduQsKBQxrvySYN3bQMn69XSfAyIirLJ CVe7ruGZgls= =v6FW -----END PGP SIGNATURE----- --Apple-Mail=_C98FCEB6-30C3-4D8C-AC79-4FA0DF8A6B42-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 14 23:29:16 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D36F25BB; Wed, 14 Aug 2013 23:29:16 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 95A832EFE; Wed, 14 Aug 2013 23:29:16 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.89,880,1367996400"; d="asc'?scan'208";a="41552649" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 14 Aug 2013 16:29:09 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Wed, 14 Aug 2013 16:29:09 -0700 From: "Eggert, Lars" To: Lawrence Stewart Subject: Re: TCP Initial Window 10 MFC (was: Re: svn commit: r252789 - stable/9/sys/netinet) Thread-Topic: TCP Initial Window 10 MFC (was: Re: svn commit: r252789 - stable/9/sys/netinet) Thread-Index: AQHOmJho/QNBxT9cUU6iUzIYTWLwbZmU2b+AgAD2kAA= Date: Wed, 14 Aug 2013 23:29:09 +0000 Message-ID: References: <201307051458.r65EwObo066269@svn.freebsd.org> <520AED2F.4050001@freebsd.org> <918804B0-BED8-4E49-9D70-01DDA6F257B3@netapp.com> In-Reply-To: <918804B0-BED8-4E49-9D70-01DDA6F257B3@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: multipart/signed; boundary="Apple-Mail=_7A75FD23-B918-4EC4-A7E3-A49AF46E2F69"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Andre Oppermann , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Aug 2013 23:29:16 -0000 --Apple-Mail=_7A75FD23-B918-4EC4-A7E3-A49AF46E2F69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Oh: The other interesting bit is that Chrome defaulted to telling the = server to use IW32 if it had no cached value... I think Google are still heavily tweaking the mechanisms. Lars On Aug 14, 2013, at 16:46, "Eggert, Lars" wrote: > Hi, >=20 > On Aug 14, 2013, at 10:36, Lawrence Stewart = wrote: >> I don't think this change should have been MFCed, at least not in its >> current form. >=20 > FYI, Google's own data as presented in the HTTPBIS working group of = the recent Berlin IETF shows that 10 is too high for ~25% of their web = connections: see slide 2 of = http://www.ietf.org/proceedings/87/slides/slides-87-httpbis-5.pdf >=20 > (That slide shows a CDF of CWND values the server used at the end of a = web transaction.) >=20 > Lars --Apple-Mail=_7A75FD23-B918-4EC4-A7E3-A49AF46E2F69 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQCVAwUBUgwSxtZcnpRveo1xAQLO+wP+JVPzI+MwO7t1ICSbdK3jo77rVtQGvHXM bb9q8dwL5YCvSjYCMb/XaKKkwuGbwIgewg1ET0c6luJoETu0KAGZbyQbq7cF43cU 2JcKFd4afdue+htr8elm7tXic2ttmyCOIyASn3aWHidgO83HcmS7w48azdP3U3YF 9BGKzC/g+8g= =vPGM -----END PGP SIGNATURE----- --Apple-Mail=_7A75FD23-B918-4EC4-A7E3-A49AF46E2F69-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 15 03:19:02 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A205399; Thu, 15 Aug 2013 03:19:02 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 602D32DF0; Thu, 15 Aug 2013 03:19:02 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 576EA7300A; Thu, 15 Aug 2013 05:23:38 +0200 (CEST) Date: Thu, 15 Aug 2013 05:23:38 +0200 From: Luigi Rizzo To: Peter Wemm Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) Message-ID: <20130815032338.GA74257@onelab2.iet.unipi.it> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <587579055.20130814154713@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Lawrence Stewart , Adrian Chadd , Lev Serebryakov , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Aug 2013 03:19:02 -0000 On Wed, Aug 14, 2013 at 12:40:19PM -0700, Peter Wemm wrote: > On Wed, Aug 14, 2013 at 11:11 AM, Adrian Chadd wrote: > > On 14 August 2013 04:47, Lev Serebryakov wrote: > > > > > >> And we should invalidate this info on ARP/route changes, or connection > >> will be lost in such cases, am I right?.. So, on each such event code > >> should look into all sockets and check, if routing/ARP information is > >> still > >> valid for them. Or we should store lists of sockets in routing and ARP > >> tables... I don't know, what is worse. > >> > > > > .. or per-CPU copies of the ARP table.. ? > > Local cache at each consumer and check a generation number to see if > it needs to be re-validated before using. The obvious problem with > this though is that big networks tend to kill your caches. if you expect this to be problematic you can partition the entries and use a different generation number per cluster. Anyways if you really want to be guaranteed you need atomic reads on the generation numbers (or ticks), which I have heard are expensive on !i386/amd64 machines. This is why I would probably try to live with races (which for arp are a non problem). cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Aug 15 03:46:20 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F1F6F9EC; Thu, 15 Aug 2013 03:46:19 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 80B1F2F5B; Thu, 15 Aug 2013 03:46:19 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 6881B7E81E; Thu, 15 Aug 2013 13:46:11 +1000 (EST) Message-ID: <520C4F03.9040601@freebsd.org> Date: Thu, 15 Aug 2013 13:46:11 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: TCP Initial Window 10 MFC References: <201307051458.r65EwObo066269@svn.freebsd.org> <520AED2F.4050001@freebsd.org> <520BB3F0.4020506@freebsd.org> In-Reply-To: <520BB3F0.4020506@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Aug 2013 03:46:20 -0000 On 08/15/13 02:44, Andre Oppermann wrote: > On 14.08.2013 04:36, Lawrence Stewart wrote: >> Hi Andre, >> >> [RE team is BCCed so they're aware of this discussion] >> >> On 07/06/13 00:58, Andre Oppermann wrote: >>> Author: andre >>> Date: Fri Jul 5 14:58:24 2013 >>> New Revision: 252789 >>> URL: http://svnweb.freebsd.org/changeset/base/252789 >>> >>> Log: >>> MFC r242266: >>> >>> Increase the initial CWND to 10 segments as defined in IETF TCPM >>> draft-ietf-tcpm-initcwnd-05. It explains why the increased initial >>> window improves the overall performance of many web services without >>> risking congestion collapse. >>> >>> As long as it remains a draft it is placed under a sysctl marking it >>> as experimental: >>> net.inet.tcp.experimental.initcwnd10 = 1 >>> When it becomes an official RFC soon the sysctl will be changed to >>> the RFC number and moved to net.inet.tcp. >>> >>> This implementation differs from the RFC draft in that it is a bit >>> more conservative in the case of packet loss on SYN or SYN|ACK >>> because >>> we haven't reduced the default RTO to 1 second yet. Also the >>> restart >>> window isn't yet increased as allowed. Both will be adjusted with >>> upcoming changes. >>> >>> Is is enabled by default. In Linux it is enabled since kernel 3.0. >> >> I haven't been fully alert to FreeBSD happenings this year so apologies >> for bringing this up so long after the MFC. >> >> I don't think this change should have been MFCed, at least not in its >> current form. Enabling the switch to IW=10 on a stable branch is >> inappropriate IMO. I also think the "net.inet.tcp.experimental" sysctl >> branch is poorly named as per the important discussion we had back in >> February [1]. I would really prefer we didn't get stuck having to keep >> it around by making a stable release with it being present. >> >> I think this commit should be backed out of stable/9 and more >> importantly, 9.2-RELEASE. > > Backing out the patch isn't really necessary, just flip the switch to > off having it revert to the RFC5681 defaults. Those who want it anyway > can simply enable it again. That doesn't address the sysctl tree naming concern or mechanism issue - please refer back to the Feb discussion; specifically the proposal to rename the experimental branch to "net.inet.tcp.nonstandard" and add an "allowed" leaf which takes a list of non-standard behaviours to allow tweaking in the stack. Leaving the sysctl branch named "experimental" conveys that the things which live under the branch are being evaluated in some way for becoming a default, which is very different to "nonstandard" which conveys that the user is twiddling things in a way which normally shouldn't be. IW=10 may become a FreeBSD default at some point, but the mechanism for enabling it should be to specify the initial window as a value in segments, and as such by allowing any non-standard value (IW=7, IW=50), I strongly argue in favour for changing the branch name from "experimental" to "nonstandard". In order to continue this discussion in the context of what we started in Feb, I still request that this change be backed out of releng/9.2 so that 9.2-RELEASE doesn't ship with it. We can continue discussion for it's future in stable/9 and head after the backout so that 9.2 isn't held up. > IW10 has become RFC6928 (experimental) in April 2013. Great for the draft authors, but irrelevant for this discussion. >> As an aside, I am intending to follow up to the Feb discussion with a >> patch that implements the basic infrastructure I proposed so that we can >> continue that discussion. > > Again I'm deeply concerned and opposed to giving end users direct control > over the IW value. I've had and seen too many cases of totally bogus > "tuning" > by cranking up random sysctls to insane values and then complaining about > FreeBSD being slow compared to Linux (and then ditching FreeBSD). Sorry, but referring to unspecified cases of stupidity resulting in loss of unquantified numbers of users as a reason against providing a controlled mechanism to change a default system parameter in a potentially harmful way is not a rational argument. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Aug 15 04:00:20 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DCFA0DAE; Thu, 15 Aug 2013 04:00:20 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A2A1A2FF7; Thu, 15 Aug 2013 04:00:20 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id r10so328386pdi.41 for ; Wed, 14 Aug 2013 21:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=j6XLCxBKieF7LMnFKJlozCgILBbaKkdCkapC/S9pmKs=; b=iOmoY9rx7nQow1LpWJDVfcB4THUqLBMeEDdKbtD0WJRLJ/3Q3WFcKf4iVUevSsAujV y/HgwhfXj7Z/hJkEtNCyUOC3QFt3QEYhG3XOPrGoxI4OmDa72DYo6/SlwFtAHaZwEZO4 OzAbArTkFgqs1aF/i4H7UorOj256MtA8a0I6blpwSOyPDsTnZuxSg9L+9MpdGVAHlNe9 QkFP9vHDhDLAT/TIONf1b2ePchJSCXxla68PqrTf7Dmy91e55+JGrG3wpf2rXXdqm0Bk WKmrcAQyPQwQO/X6Mj/FDONmN3y0QG5F2cwVuE+H1m6PD8F2IPdGc1hErE09jl+lJy7t 1T3w== X-Received: by 10.68.220.1 with SMTP id ps1mr13329263pbc.30.1376539219874; Wed, 14 Aug 2013 21:00:19 -0700 (PDT) Received: from [192.168.1.64] (108-64-226-69.lightspeed.sntcca.sbcglobal.net. [108.64.226.69]) by mx.google.com with ESMTPSA id x8sm54087305pbb.39.2013.08.14.21.00.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Aug 2013 21:00:18 -0700 (PDT) References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <587579055.20130814154713@serebryakov.spb.ru> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Vijay Singh Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) Date: Wed, 14 Aug 2013 21:00:16 -0700 To: Adrian Chadd Cc: Lawrence Stewart , Lev Serebryakov , Luigi Rizzo , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Aug 2013 04:00:20 -0000 Is that what FLOWTABLE does? Also we need a mechanism to record time spent a= t various layers in the stack. Luigi has used his own methods but we're lack= ing something more generic. At work we have some crude tools that use mcount= information to indirectly measure costs but they are not reliable and only p= rovide partial information. Sent from my iPhone On Aug 14, 2013, at 11:11 AM, Adrian Chadd wrote: > On 14 August 2013 04:47, Lev Serebryakov wrote: >=20 >=20 >> And we should invalidate this info on ARP/route changes, or connection >> will be lost in such cases, am I right?.. So, on each such event code >> should look into all sockets and check, if routing/ARP information is >> still >> valid for them. Or we should store lists of sockets in routing and ARP >> tables... I don't know, what is worse. >=20 > .. or per-CPU copies of the ARP table.. ? >=20 >=20 >=20 > -adrian > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://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 Aug 15 07:41:17 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 62C2790; Thu, 15 Aug 2013 07:41:17 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3DF392CD2; Thu, 15 Aug 2013 07:41:17 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r7F7fAvg020956 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 15 Aug 2013 00:41:14 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <520C8611.4030707@freebsd.org> Date: Thu, 15 Aug 2013 15:41:05 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: TSO and FreeBSD vs Linux References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <520BDEAE.9000104@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Lawrence Stewart , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Aug 2013 07:41:17 -0000 On 8/15/13 7:27 AM, Kevin Oberman wrote: > On Wed, Aug 14, 2013 at 12:46 PM, Julian Elischer > > wrote: > > > so I ran on 9.2-beta ( a week or two old) and it had similar > problems.. > only worse.. 9.2 actually sends multiple packets when is doesn't > need to.. > http://people.freebsd.org/~julian/fbsd9.png > > > > Ack! (Sorry) I could have sworn that this had been fixed. Has it > been re-broken? I don't really know why it did that, but maybe its' something to do with the code that tries to avoid sending more than 16 mbufs to the Xen network.. > -- > R. Kevin Oberman, Network Engineer > E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Aug 15 14:01:35 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AF73A94 for ; Thu, 15 Aug 2013 14:01:35 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7467C2247 for ; Thu, 15 Aug 2013 14:01:35 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id r7FE1LoA014593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Aug 2013 15:01:21 +0100 (BST) Date: Thu, 15 Aug 2013 15:01:24 +0100 From: Karl Pielorz To: Daniel Hartmeier Subject: Re: Create CARP interface in state INIT? Message-ID: <923A5641B77139EF4FBCB762@Mail-PC.tdx.co.uk> In-Reply-To: <20130813133458.GA31184@insomnia.benzedrine.cx> References: <20130813133458.GA31184@insomnia.benzedrine.cx> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Aug 2013 14:01:35 -0000 --On 13 August 2013 15:34 +0200 Daniel Hartmeier wrote: > So, don't configure the carp interface in rc.conf, but do it in > /etc/rc.local, and be careful to add the address while the vhid is not > yet configured, as in: > > ifconfig carp0 create > ifconfig carp0 inet 192.168.107.21 > ifconfig carp0 down > ifconfig carp0 vhid 21 pass secret advskew 100 Hmmm, I tried that - and it leaves the interface in a 'weird' state (at least not the state I was expecting): carp0: flags=9 metric 0 mtu 1500 inet 192.168.107.21 netmask 0xffffff00 nd6 options=21 Subsequently doing a 'ifconfig carp0' doesn't bring it up either :( -Karl From owner-freebsd-net@FreeBSD.ORG Thu Aug 15 18:04:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 889E9992 for ; Thu, 15 Aug 2013 18:04:33 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21F0D2FBB for ; Thu, 15 Aug 2013 18:04:32 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id q58so842448wes.20 for ; Thu, 15 Aug 2013 11:04:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=uW6L7yG3faQ5gga+Dlif+yUx2tKfsj3kX2hkzavgX2Q=; b=LZ4wa8L+SWn3327+ptEtxTnBMlkhgPZbxhhriRHm4rdFd4TV6ETwGolhbPLlWD6yi1 s/4PKm/e0Syy/93lLPP18YJYgUApHxWTcO7hajruae8+Q674QIefVXd/7oI4B3tzsyFM h8NIM30uKp6Vvl9YC4Wbl/eBVVa6VwuSXpCEjM/S3pockC0mMRWGanHXNlkr25AvXQfF LYrhzCCwEge5oO8tCunMVDQbuPk3ig+2U/enCsPH8suUCumq/hm2262Hq7QneYD0pkCK HrWdi1iFirxMGLkKV2aJJusAAtgzCWeJoIlEbculG81AQ31nSjZvIIJUSMzkr5EuDyqo fqdg== X-Gm-Message-State: ALoCoQmmUS0xvkS2ZpVv39xxA0GJX1TB9pnzkacDiUCQPg/QAV9OdW1wzsblrlKv0mXs6XEy2RAN X-Received: by 10.180.12.45 with SMTP id v13mr2099592wib.57.1376579699442; Thu, 15 Aug 2013 08:14:59 -0700 (PDT) Received: from [100.79.218.189] (22.26.90.92.rev.sfr.net. [92.90.26.22]) by mx.google.com with ESMTPSA id l5sm71744wia.6.2013.08.15.08.14.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Aug 2013 08:14:58 -0700 (PDT) References: <20130813133458.GA31184@insomnia.benzedrine.cx> <923A5641B77139EF4FBCB762@Mail-PC.tdx.co.uk> Mime-Version: 1.0 (1.0) In-Reply-To: <923A5641B77139EF4FBCB762@Mail-PC.tdx.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3AC68FE5-2C01-4C73-B8F9-93C278DF89A7@my.gd> X-Mailer: iPhone Mail (10B144) From: Damien Fleuriot Subject: Re: Create CARP interface in state INIT? Date: Thu, 15 Aug 2013 17:13:15 +0200 To: Karl Pielorz Cc: "freebsd-net@FreeBSD.org" , Daniel Hartmeier X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Aug 2013 18:04:33 -0000 On 15 Aug 2013, at 16:01, Karl Pielorz wrote: >=20 >=20 > --On 13 August 2013 15:34 +0200 Daniel Hartmeier wr= ote: >=20 >> So, don't configure the carp interface in rc.conf, but do it in >> /etc/rc.local, and be careful to add the address while the vhid is not >> yet configured, as in: >>=20 >> ifconfig carp0 create >> ifconfig carp0 inet 192.168.107.21 >> ifconfig carp0 down >> ifconfig carp0 vhid 21 pass secret advskew 100 >=20 > Hmmm, I tried that - and it leaves the interface in a 'weird' state (at le= ast not the state I was expecting): >=20 > carp0: flags=3D9 metric 0 mtu 1500 > inet 192.168.107.21 netmask 0xffffff00 > nd6 options=3D21 >=20 > Subsequently doing a 'ifconfig carp0' doesn't bring it up either :( >=20 > -Karl >=20 Running CARP in production from rc.conf fine here. What version of the OS are you using ? From owner-freebsd-net@FreeBSD.ORG Thu Aug 15 18:33:43 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B7C6E97 for ; Thu, 15 Aug 2013 18:33:43 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7E5112197 for ; Thu, 15 Aug 2013 18:33:43 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id r7FIXZqE035766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Aug 2013 19:33:35 +0100 (BST) Date: Thu, 15 Aug 2013 19:33:38 +0100 From: Karl Pielorz To: Damien Fleuriot Subject: Re: Create CARP interface in state INIT? Message-ID: In-Reply-To: <3AC68FE5-2C01-4C73-B8F9-93C278DF89A7@my.gd> References: <20130813133458.GA31184@insomnia.benzedrine.cx> <923A5641B77139EF4FBCB762@Mail-PC.tdx.co.uk> <3AC68FE5-2C01-4C73-B8F9-93C278DF89A7@my.gd> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-net@FreeBSD.org, Daniel Hartmeier X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Aug 2013 18:33:43 -0000 --On 15 August 2013 17:13:15 +0200 Damien Fleuriot wrote: >> Hmmm, I tried that - and it leaves the interface in a 'weird' state (at >> least not the state I was expecting): >> >> carp0: flags=9 metric 0 mtu 1500 >> inet 192.168.107.21 netmask 0xffffff00 >> nd6 options=21 >> >> Subsequently doing a 'ifconfig carp0' doesn't bring it up either :( > Running CARP in production from rc.conf fine here. Yeah, we have a number of boxes also using it from rc.conf - I'm trying to avoid rc.conf here though - as I need the interfaces to come up as INIT (i.e. not enabled / up) - to avoid any possibility of the box coming up, and 'stealing' MASTER even if the other machine is down... (something which you apparently can't achieve with rc.conf). > What version of the OS are you using ? 9.2-RC2 on amd64. -Karl From owner-freebsd-net@FreeBSD.ORG Thu Aug 15 18:47:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E2FB04A8 for ; Thu, 15 Aug 2013 18:47:43 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7C4CF227B for ; Thu, 15 Aug 2013 18:47:43 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id x55so881666wes.4 for ; Thu, 15 Aug 2013 11:47:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=cIxgLcgEY2BEs2Scjz6An3uPRxFGwHobtUVIyLvFwZI=; b=h1TwZv8sNW2jbtDdDwS2ir2/heh72pmo61jbHCB3kEbnnG4sRdGxDQjibTUGW0ue4d w+s6ApfTbEjA/+JGtoPLetILUphz9AP35NNYIZMuVT0w9An2D50EBQVd75LpevxSAgkT avti1N6QSK2jlXtpgB8H5JvdQTVPqJW06pq9/wLTtJYVEA1OcPGHzJTxvrvPCbeYePdX OWsxQbZNVwNwlVJo5EyYfQ+PR0zoVW21V1THFVzQd8TSIbACh5YjrOHs9+X2nrRlTiuJ yHIJq17VVmtGiuKSyKVX9a++1TCj7f81m7AXjSDKwK84XZmPp9P/qr728JfDaMEHHB4j RewQ== X-Gm-Message-State: ALoCoQnnxy2GdWTnfBqI9Y4mpudB8EjXHDYdqMsy+oXkFh5574RQJKOYHu3GguKTBJgnLt1U5zIY X-Received: by 10.180.126.97 with SMTP id mx1mr2707926wib.10.1376591977715; Thu, 15 Aug 2013 11:39:37 -0700 (PDT) Received: from [100.79.218.189] (22.26.90.92.rev.sfr.net. [92.90.26.22]) by mx.google.com with ESMTPSA id jf2sm1058467wic.2.2013.08.15.11.39.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Aug 2013 11:39:37 -0700 (PDT) References: <20130813133458.GA31184@insomnia.benzedrine.cx> <923A5641B77139EF4FBCB762@Mail-PC.tdx.co.uk> <3AC68FE5-2C01-4C73-B8F9-93C278DF89A7@my.gd> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <72C131E1-124B-4E60-852E-2C9C7A1C8180@my.gd> X-Mailer: iPhone Mail (10B144) From: Damien Fleuriot Subject: Re: Create CARP interface in state INIT? Date: Thu, 15 Aug 2013 20:37:54 +0200 To: Karl Pielorz Cc: "freebsd-net@FreeBSD.org" , Daniel Hartmeier X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Aug 2013 18:47:43 -0000 On 15 Aug 2013, at 20:33, Karl Pielorz wrote: >=20 >=20 > --On 15 August 2013 17:13:15 +0200 Damien Fleuriot wrote: >=20 >>> Hmmm, I tried that - and it leaves the interface in a 'weird' state (at >>> least not the state I was expecting): >>>=20 >>> carp0: flags=3D9 metric 0 mtu 1500 >>> inet 192.168.107.21 netmask 0xffffff00 >>> nd6 options=3D21 >>>=20 >>> Subsequently doing a 'ifconfig carp0' doesn't bring it up either :( >=20 >> Running CARP in production from rc.conf fine here. >=20 > Yeah, we have a number of boxes also using it from rc.conf - I'm trying to= avoid rc.conf here though - as I need the interfaces to come up as INIT (i.= e. not enabled / up) - to avoid any possibility of the box coming up, and 's= tealing' MASTER even if the other machine is down... (something which you ap= parently can't achieve with rc.conf). >=20 >> What version of the OS are you using ? >=20 > 9.2-RC2 on amd64. >=20 > -Karl >=20 Oh I'm sorry I got that the other way around, thought you had it in INIT fro= m rc.conf and wanted to fix that. As has been pointed out, you prolly want to use rc.local My apologies for the noise.= From owner-freebsd-net@FreeBSD.ORG Fri Aug 16 08:54:43 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 91F4C6B9; Fri, 16 Aug 2013 08:54:43 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6DC072901; Fri, 16 Aug 2013 08:54:43 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r7G8sYnV062506 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 01:54:40 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <520DE8C5.8070508@freebsd.org> Date: Fri, 16 Aug 2013 16:54:29 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> In-Reply-To: <20130814102109.GA63246@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Aug 2013 08:54:43 -0000 On 8/14/13 6:21 PM, Luigi Rizzo wrote: > On Wed, Aug 14, 2013 at 05:23:02PM +1000, Lawrence Stewart wrote: >> On 08/14/13 16:33, Julian Elischer wrote: >>> On 8/14/13 11:39 AM, Lawrence Stewart wrote: >>>> On 08/14/13 03:29, Julian Elischer wrote: >>>>> I have been tracking down a performance embarrassment on AMAZON EC2 and >>>>> have found it I think. >>>> Let us please avoid conflating performance with throughput. The >>>> behaviour you go on to describe as a performance embarrassment is >>>> actually a throughput difference, and the FreeBSD behaviour you're >>>> describing is essentially sacrificing throughput and CPU cycles for >>>> lower latency. That may not be a trade-off you like, but it is an >>>> important factor in this discussion. > ... >> Sure, there's nothing wrong with holding throughput up as a key >> performance metric for your use case. >> >> I'm just trying to pre-empt a discussion that focuses on one metric and >> fails to consider the bigger picture. > ... >>> I could see no latency reversion. >> You wouldn't because it would be practically invisible in the sorts of >> tests/measurements you're doing. Our good friends over at HRT on the >> other hand would be far more likely to care about latency on the order >> of microseconds. Again, the use case matters a lot. > ... >>> so, does "Software LRO" mean that LRO on hte NIC should be ON or OFF to >>> see this? >> I think (check the driver code in question as I'm not sure) that if you >> "ifconfig lro" and the driver has hardware support or has been made >> aware of our software implementation, it should DTRT. > The "lower throughput than linux" that julian was seeing is either > because of a slow (CPU-bound) sender or slow receiver. Given that > the FreeBSD tx path is quite expensive (redoing route and arp lookups > on every packet, etc.) I highly suspect the sender side is at fault. if we send bigger packets then we do less lookups do we not? > > Ack coalescing, LRO, GRO are limited to the set of packets that you > receive in the same batch, which in turn is upper bounded by the > interrupt moderation delay. Apart from simple benchmarks with only > a few flows, it is very hard that ack/lro/gro can coalesce more > than a few segments for the same flow. > > But the real fix is in tcp_output. > > In fact, it has never been the case that an ack (single or coalesced) > triggers an immediate transmission in the output path. We had this > in the past (Silly Window Syndrome) and there is code that avoids > sending less than 1-mtu under appropriate conditions (there is more > data to push out anyways, no NODELAY, there are outstanding acks, > the window can open further). In all these cases there is no > reasonable way to experience the difference in terms of latency. > > If one really cares, e.g. the High Speed Trading example, this is > a non issue because any reasonable person would run with TCP_NODELAY > (and possibly disable interrupt moderation), and optimize for latency > even on a per flow basis. > > In terms of coding effort, i suspect that by replacing the 1-mtu > limit (t_maxseg i believe is the variable that we use in the SWS > avoidance code) with 1-max-tso-segment we can probably achieve good > results with little programming effort. > > Then the problem remains that we should keep a copy of route and > arp information in the socket instead of redoing the lookups on > every single transmission, as they consume some 25% of the time of > a sendto(), and probably even more when it comes to large tcp > segments, sendfile() and the like. > > cheers > luigi > > From owner-freebsd-net@FreeBSD.ORG Fri Aug 16 14:56:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6E780E85 for ; Fri, 16 Aug 2013 14:56:19 +0000 (UTC) (envelope-from bounce-md_30057948.520e3a0c.v1-ca73a110a6294026859ce5c809fc0fe0@mandrillapp.com) Received: from mail112.us4.mandrillapp.com (mail112.us4.mandrillapp.com [205.201.136.112]) by mx1.freebsd.org (Postfix) with ESMTP id 420852C32 for ; Fri, 16 Aug 2013 14:56:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mandrill; d=mail112.us4.mandrillapp.com; h=From:Sender:Subject:Message-Id:To:Date:MIME-Version:Content-Type; i=sales@mail112.us4.mandrillapp.com; bh=YUib3HgVTc7HwmMiopLBX+/e8QQ=; b=QjC9JVxXgxjCg9VYjiPSlKyf++afJl08h1n7wIxstjX5Qt9xNb8P3nB/DJIScIiB+gvNUra6cCE2 Hvebeiav+TFZ5uohlLQeVOEf2d6KC0ngQcjgVzXnwmpjTIvrrPbbZjuKACZxdClhRIuIL/5HhGiz crRxwdewB9YzZlU0BYY= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=mandrill; d=mail112.us4.mandrillapp.com; b=LcypTpDjDp2d4C3Fx+qHZVkR/RK49urzaSYnR5S31ux/2RG6GLBd/+FSaede4xuag8UV+piO/Fqw cqwUoWLPGFFPx34VQ4avZppnGgzDO9qoLrZGchWZdlrI0l4MACpNbjczYVpzg6fOnwSyrO9Re5v5 Z3Fag7mNQbZ9N5ajut4=; Received: from localhost (127.0.0.1) by mail112.us4.mandrillapp.com id h1oup614i28k for ; Fri, 16 Aug 2013 14:41:16 +0000 (envelope-from ) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c.mandrillapp.com; i=@c.mandrillapp.com; q=dns/txt; s=mandrill; t=1376664076; h=From : Sender : Subject : Message-Id : To : Date : MIME-Version : Content-Type : From : Subject : Date : X-Mandrill-User : List-Unsubscribe; bh=lD8V35N76SZYneJU8jz/AfAKsB/0f5veo4ugUmXkrIw=; b=l3ppbkMeTAUkGK8QR/lQ7rh9koyA8tfULdRibmJpY4pWU6dW+fstflJHuekimJ70ArONqA akk6cAzA+TjALT7u1pjRO991oXXzdHuUwexUU/fLCjjJx9/mfJsmLtKZChq893Bux1hhqXWY YPK+yt1p1sSY8xZ0IkfIe+5KS5vfg= From: Sender: Subject: Asic Bitcoin Sales X-Bounce-Tracking-Info: Message-Id: To: freebsd-net Received: from [82.25.232.86] by mandrillapp.com id ca73a110a6294026859ce5c809fc0fe0; Fri, 16 Aug 2013 14:41:16 +0000 X-Report-Abuse: Please forward a copy of this message, including all headers, to abuse@mandrill.com X-Report-Abuse: You can also report abuse here: http://mandrillapp.com/contact/abuse?id=30057948.ca73a110a6294026859ce5c809fc0fe0 X-Mandrill-User: md_30057948 Date: Fri, 16 Aug 2013 14:41:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Aug 2013 14:56:19 -0000 = Asic-technologies.com = New Cheaper Prices - difficulty now 50M ! Visit Us USB Block Miners from ASICMINER now 0.58 BTC each !! FREE SHIPPING Mining board's supplied , Case, power supply , On-board heat sink , USB connectors. Ready assembled All the boards are linked together , With one main controller. Easy to Install Software (Disk Provided) Simple Plug and play. = Asic-technologies.com = From owner-freebsd-net@FreeBSD.ORG Fri Aug 16 16:59:31 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9327B508; Fri, 16 Aug 2013 16:59:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CB2BE2418; Fri, 16 Aug 2013 16:59:30 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id t61so1856762wes.17 for ; Fri, 16 Aug 2013 09:59:29 -0700 (PDT) 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=jDlv/RFR8E2jueVSB36eBU7JjgrTChPjSgLaGZ3L3+4=; b=Sl6mhd49glKP1fuuYoWC+G4pySKc8/UgqSaMGdwUsaj2pox1r3orDFY5QdWqfjpJOV 3FrHnPVeXtrdHXVmaJc7sqAPG1haZGXvsXGNw018WVTCqVI7ehhbQUwqfNCCzP5l7dfF iBVbstC20QCz3QTIz4nRzSTJEf+0+MsomAQbGjm/9DiyPmFnYxMksaEt3PyOTtkWbS4e tQVpCIldg7Fz75ukkAKByH1HNNs1apHfQyt7TP3lluTqAf/wrG2cjbEFjKRe6Z3hgzic jm6Abp/vrClcKIQuXznm/tmKa96Zgv4YivoUS9j9+RpsBZme21HVhypf/bmfHUgYOk17 SsRQ== MIME-Version: 1.0 X-Received: by 10.194.94.137 with SMTP id dc9mr1872442wjb.38.1376672369219; Fri, 16 Aug 2013 09:59:29 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Fri, 16 Aug 2013 09:59:29 -0700 (PDT) In-Reply-To: References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <587579055.20130814154713@serebryakov.spb.ru> Date: Fri, 16 Aug 2013 09:59:29 -0700 X-Google-Sender-Auth: 3Fq6pHFMabLHSX8_nd2XWBNFuJk Message-ID: Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) From: Adrian Chadd To: Vijay Singh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Lawrence Stewart , Lev Serebryakov , Luigi Rizzo , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Aug 2013 16:59:31 -0000 Luigi, Did you ever publish your patches or methodology for doing sampling? -adrian On 14 August 2013 21:00, Vijay Singh wrote: > Is that what FLOWTABLE does? Also we need a mechanism to record time spent > at various layers in the stack. Luigi has used his own methods but we're > lacking something more generic. At work we have some crude tools that use > mcount information to indirectly measure costs but they are not reliable > and only provide partial information. > > Sent from my iPhone > > On Aug 14, 2013, at 11:11 AM, Adrian Chadd wrote: > > > On 14 August 2013 04:47, Lev Serebryakov wrote: > > > > > >> And we should invalidate this info on ARP/route changes, or connection > >> will be lost in such cases, am I right?.. So, on each such event code > >> should look into all sockets and check, if routing/ARP information is > >> still > >> valid for them. Or we should store lists of sockets in routing and ARP > >> tables... I don't know, what is worse. > > > > .. or per-CPU copies of the ARP table.. ? > > > > > > > > -adrian > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://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 Aug 16 17:06:24 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F36C479B; Fri, 16 Aug 2013 17:06:23 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C11782494; Fri, 16 Aug 2013 17:06:22 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id eh20so1678267lab.18 for ; Fri, 16 Aug 2013 10:06:20 -0700 (PDT) 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=XOdkJtOatgfP643zGiwSeS5LXtbY1VR6D1DYweeYWdo=; b=ZMF/1mizW2UjfEmcUdd6QQ/NNaTGLnDI8LwFJoEBtzGzDg6Xvrfs/h3u3Y4ovJEm+6 i464HAWlPzrvswPecUipha860bN/q5zYplLCkPT9WoG0v/2mTTxXwWVaWZ7F7MOkLs1t QFIQ/GBrR3kNNd3SmJDDRdupsRLt0Oajs9aPHo5BJFkXBUotQWSbsmEZP6d4MNU2Z61r TACYcmOR/92nWR7ABhkuwHqZfxYmXA1qqGayDjG3LsVvPAthEcfiPI+IN2jDeEQ2eLP7 YMszodLuGH5JR3rQ14bpPCm1bUXIz+OfjiLujFOJLTiU84Wf5S2cuPcLO1n8SuqYLAOL cotw== MIME-Version: 1.0 X-Received: by 10.112.0.173 with SMTP id 13mr3063592lbf.8.1376672780437; Fri, 16 Aug 2013 10:06:20 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Fri, 16 Aug 2013 10:06:20 -0700 (PDT) In-Reply-To: References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <587579055.20130814154713@serebryakov.spb.ru> Date: Fri, 16 Aug 2013 19:06:20 +0200 X-Google-Sender-Auth: 0EcKRT-rFCN6SMjG8QK0FyHc4Co Message-ID: Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) From: Luigi Rizzo To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Lawrence Stewart , Lev Serebryakov , FreeBSD Net , Vijay Singh X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Aug 2013 17:06:24 -0000 the usenix paper and talk https://www.usenix.org/conference/usenixfederatedconferencesweek/netmap-novel-framework-fast-packet-io should give a short description of what i did. Basically i manually insert returns (and free mbufs and resources) in some place in the path and then compute the time consumed by the code as the inverse of the average pps over 0.1 .. 1s intervals. By moving the point where i place the return, i can estimate the cost of the various sections of code involved. cheers luigi On Fri, Aug 16, 2013 at 6:59 PM, Adrian Chadd wrote: > Luigi, > > Did you ever publish your patches or methodology for doing sampling? > > > > -adrian > > > On 14 August 2013 21:00, Vijay Singh wrote: > >> Is that what FLOWTABLE does? Also we need a mechanism to record time >> spent at various layers in the stack. Luigi has used his own methods but >> we're lacking something more generic. At work we have some crude tools that >> use mcount information to indirectly measure costs but they are not >> reliable and only provide partial information. >> >> Sent from my iPhone >> >> On Aug 14, 2013, at 11:11 AM, Adrian Chadd wrote: >> >> > On 14 August 2013 04:47, Lev Serebryakov wrote: >> > >> > >> >> And we should invalidate this info on ARP/route changes, or connection >> >> will be lost in such cases, am I right?.. So, on each such event code >> >> should look into all sockets and check, if routing/ARP information is >> >> still >> >> valid for them. Or we should store lists of sockets in routing and ARP >> >> tables... I don't know, what is worse. >> > >> > .. or per-CPU copies of the ARP table.. ? >> > >> > >> > >> > -adrian >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > http://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-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Fri Aug 16 17:59:31 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DEB35A14; Fri, 16 Aug 2013 17:59:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 20182276B; Fri, 16 Aug 2013 17:59:30 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hi8so1063431wib.15 for ; Fri, 16 Aug 2013 10:59:29 -0700 (PDT) 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=IxUKeSU9a3GYco3yy2FckMPeMc+STXLr8WYJmCWJVGg=; b=Uoclntpfof6vZPcqRON4UKizrLCzKZYfhDnzrQ0UZ10chcTgIiErTPeBCVL0gFcZv4 bKdZHFnwMVOvgIpx1fqGqbPi4bT5w6Jo+lceuVPycsBL7rH7sYI2p1FDRH8U8QSU7C1C tvOEa404hcE6ney6deE8fWGgNc9dxiZ2YAWlpymGGxaP8bccYFvuf5qn/Jc5mFJRM1D1 VuHFVooREcXP5TsIHbnw8bfUNDb0oepCdIJ6FEzFXADIpQleIhZjxqHR6fAYQhcfwXSh 17gWQkSRHXgkGkvxPh/m7u5oGUJdsiLr1rnzhJIPnylKGVIA3IbaQhlllnmFjWfCxtIv I2Tw== MIME-Version: 1.0 X-Received: by 10.180.20.116 with SMTP id m20mr63138wie.46.1376675969210; Fri, 16 Aug 2013 10:59:29 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Fri, 16 Aug 2013 10:59:29 -0700 (PDT) In-Reply-To: References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <587579055.20130814154713@serebryakov.spb.ru> Date: Fri, 16 Aug 2013 10:59:29 -0700 X-Google-Sender-Auth: vk_WhoyFlF0yEi9xSTBFb5BykLE Message-ID: Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Lawrence Stewart , Lev Serebryakov , FreeBSD Net , Vijay Singh X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Aug 2013 17:59:31 -0000 On 16 August 2013 10:06, Luigi Rizzo wrote: > the usenix paper and talk > > https://www.usenix.org/conference/usenixfederatedconferencesweek/netmap-novel-framework-fast-packet-io > should give a short description of what i did. > > Basically i manually insert returns (and free mbufs and resources) > in some place in the path and then compute the time consumed by > the code as the inverse of the average pps over 0.1 .. 1s intervals. > By moving the point where i place the return, i can estimate the > cost of the various sections of code involved. > > Cool. I think I've seen this stuff. I may have to spin up netmap soon, if only to look at how much more efficient (and how!) you're driving the CPU and IO bus. -adrian From owner-freebsd-net@FreeBSD.ORG Sat Aug 17 13:14:12 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 97A8434A for ; Sat, 17 Aug 2013 13:14:12 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm10-vm2.bullet.mail.ne1.yahoo.com (nm10-vm2.bullet.mail.ne1.yahoo.com [98.138.90.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 38FE127D1 for ; Sat, 17 Aug 2013 13:14:11 +0000 (UTC) Received: from [98.138.90.50] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 17 Aug 2013 13:14:05 -0000 Received: from [98.138.89.195] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 17 Aug 2013 13:14:05 -0000 Received: from [127.0.0.1] by omp1053.mail.ne1.yahoo.com with NNFMP; 17 Aug 2013 13:14:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 197983.25334.bm@omp1053.mail.ne1.yahoo.com Received: (qmail 9235 invoked by uid 60001); 17 Aug 2013 13:14:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1376745244; bh=OzcZzVirSclyM3Ukul+yM9tJ8nb8ROoZboR/jmt4GIM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=yaUbd+VG0meJRL7SNKOSwvLY/DJHUaqPX4yUtNcl9LqzmsVABEWRYnyYPiTa9kFqM14aD95piG2GOffGnxli6v8WpSsnyo45VBK7WTY+RCvHD+v27x7VKhp3CLuYN9GJAHS6rKV0h0VWlNd/XlrvKLxd3yJ+xHfyytph4WWXA7Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pg5V6deAKuYdNwiokXU3CjVG3690avRYkUb4d5uBz7TKUdIOGYaT2a22A7PSjfE26Gad6ozc/eJqS9SFGWTIb0ScRbwYy4SbLS0cFABRE1b9RYgzQQWYazFJBmnlBISpqeYXr0u63ttRP5RonQJQEujgv6cMSyovXqq1dwTDZTQ=; X-YMail-OSG: mHYdQw4VM1lxOVuxutIHIVwDcMmUSK22aW3LzbLqxsfU.l_ OXEp9kTMMQ5240bL8O1O.YLkqHCTICllvay3AEKxVjY7yMrz91AIINB8KRmX WKQHbUc0LM1z0mh8eTAOZ49ORQEFxZdDGSWUueqaEU_aOxIaqFkVWcXR_JMd jVzv9Pciq3KRJLAagnOWKE6irMTEr_j4wPcY1WleSZgNp.X_OzsOQBQWlSVx C8iwwMvwZpWmr5JWQJjkDTp8QO6V9XgkHcn3tmiNkNvX2w.yhLFoQXwvyeAE llLk0PF3wtNpYPfMJjUEEbf8xfgYK1Y.BpoHKi6bDHSueFInueMVkEvuMOqz JA4AznrWxOp2ULvcNOwPFR2SGarY7xBvddg7NJMqOWgZnz0FwrTl4wPDxwFx QkzMazNaum_m9TXbyF4lzW57H1GHu8At7Cy1_nvHpG8B84GecSPIzgkO5wUA cRXm84x6KvFydpNfMNQbWEfVQNU1mdutD5ass2bm32mfj8WzpCcMvZ25etZ5 rDfiCB_E0b1kVGOz1qjclvGRQB0qDskkcWnaCxrt.VP_5zZInryl9dC0KUHI bjLTtNhyNcQf.Lm53v_vgd1IzJmXabiaT7lmCU9eHh4tukFVHo2idn8nx8HC NxJbTQYxM5L38SzL0etTtyfxzq8IQo7aDp3Pi_0eHzQ-- Received: from [98.203.118.124] by web121606.mail.ne1.yahoo.com via HTTP; Sat, 17 Aug 2013 06:14:04 PDT X-Rocket-MIMEInfo: 002.001, SG9yc2Vob2NrZXkuIFdoYXQgYXJlIHlvdSBndXlzIHJ1bm5pbmcgd2l0aCwgUDRzPwoKTW9kZXJuIGNwdXMgYXJlIG1hZ25pZmljZW50bHkgZmFzdC4gVGhlIHRyaXZpYWxpdHkgb2YgbG9va3VwcyBpcyBhIG5vbi1pc3N1ZcKgCmluIGFsbW9zdCBhbGwgY2FzZXMuIFRoZSBhYmlsaXR5IG9mIG1vZGVybiBjcHVzIHRvIGZpbGwgYSB0cmFuc21pdCBxdWV1ZSBmYXN0ZXIKdGhhbiB0aGUgZGF0YSBjYW4gYmUgdHJhbnNtaXR0ZWQgaXMgaW5jb250cm92ZXJ0aWJsZS4KCldpdGggVENQIHlvdSBoYXZlIHdpbmRvd3MBMAEBAQE- X-Mailer: YahooMailWebService/0.8.154.571 References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> Message-ID: <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> Date: Sat, 17 Aug 2013 06:14:04 -0700 (PDT) From: Barney Cordoba Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) To: Luigi Rizzo , Lawrence Stewart In-Reply-To: <20130814102109.GA63246@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Barney Cordoba List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 13:14:12 -0000 Horsehockey. What are you guys running with, P4s?=0A=0AModern cpus are magn= ificently fast. The triviality of lookups is a non-issue=A0=0Ain almost all= cases. The ability of modern cpus to fill a transmit queue faster=0Athan t= he data can be transmitted is incontrovertible.=0A=0AWith TCP you have wind= ows and things; trying to drill down to hardware=0Ainefficiencies as if you= 're running on a 200Mhz P4 is just silly.=0A=0AI abandoned hardware offload= s back when someone tried to sell me on data=0Acompression boards; the trut= h is that the IO overhead of copying to and from=A0=0Athe board was higher = than the cpu cycles needed to compress the data.=0A=0A=0AThe failure to und= erstand how IO and locks interfere with traffic flow on=A0=0Amulticore syst= ems is the biggest problem with driver development; all of this=0Achatter a= bout moderation is simply a waste of time; such things are completely=0Atun= able; a task that gets far too little attention IMO. Tuning can make a worl= d=0Aof difference if you understand what you're doing.=0A=0AThe idea that h= aving 400K ints/second to gain a tock of throughput is an acceptable=0Atrad= e-off is patently absurd.=0A=0AEFFICIENCY is tantamount. Throughput is almo= st always a tuning issue.=0A=0A=0ABC=0A=0A________________________________= =0A From: Luigi Rizzo =0ATo: Lawrence Stewart =0ACc: FreeBSD Net =0ASent: Wednesday, Augu= st 14, 2013 6:21 AM=0ASubject: it's the output, not ack coalescing (Re: TSO= and FreeBSD vs Linux)=0A =0A=0AOn Wed, Aug 14, 2013 at 05:23:02PM +1000, L= awrence Stewart wrote:=0A> On 08/14/13 16:33, Julian Elischer wrote:=0A> > = On 8/14/13 11:39 AM, Lawrence Stewart wrote:=0A> >> On 08/14/13 03:29, Juli= an Elischer wrote:=0A> >>> I have been tracking down a performance embarras= sment on AMAZON EC2 and=0A> >>> have found it I think.=0A> >> Let us please= avoid conflating performance with throughput. The=0A> >> behaviour you go = on to describe as a performance embarrassment is=0A> >> actually a throughp= ut difference, and the FreeBSD behaviour you're=0A> >> describing is essent= ially sacrificing throughput and CPU cycles for=0A> >> lower latency. That = may not be a trade-off you like, but it is an=0A> >> important factor in th= is discussion.=0A...=0A> Sure, there's nothing wrong with holding throughpu= t up as a key=0A> performance metric for your use case.=0A> =0A> I'm just t= rying to pre-empt a discussion that focuses on one metric and=0A> fails to = consider the bigger picture.=0A...=0A> > I could see no latency reversion.= =0A> =0A> You wouldn't because it would be practically invisible in the sor= ts of=0A> tests/measurements you're doing. Our good friends over at HRT on = the=0A> other hand would be far more likely to care about latency on the or= der=0A> of microseconds. Again, the use case matters a lot.=0A...=0A> > so,= does "Software LRO" mean that LRO on hte NIC should be ON or OFF to=0A> > = see this?=0A> =0A> I think (check the driver code in question as I'm not su= re) that if you=0A> "ifconfig lro" and the driver has hardware support= or has been made=0A> aware of our software implementation, it should DTRT.= =0A=0AThe "lower throughput than linux" that julian was seeing is either=0A= because of a slow (CPU-bound) sender or slow receiver. Given that=0Athe Fre= eBSD tx path is quite expensive (redoing route and arp lookups=0Aon every p= acket, etc.) I highly suspect the sender side is at fault.=0A=0AAck coalesc= ing, LRO, GRO are limited to the set of packets that you=0Areceive in the s= ame batch, which in turn is upper bounded by the=0Ainterrupt moderation del= ay. Apart from simple benchmarks with only=0Aa few flows, it is very hard t= hat ack/lro/gro can coalesce more=0Athan a few segments for the same flow.= =0A=0A=A0=A0=A0 But the real fix is in tcp_output.=0A=0AIn fact, it has nev= er been the case that an ack (single or coalesced)=0Atriggers an immediate = transmission in the output path.=A0 We had this=0Ain the past (Silly Window= Syndrome) and there is code that avoids=0Asending less than 1-mtu under ap= propriate conditions (there is more=0Adata to push out anyways, no NODELAY,= there are outstanding acks,=0Athe window can open further).=A0 In all thes= e cases there is no=0Areasonable way to experience the difference in terms = of latency.=0A=0AIf one really cares, e.g. the High Speed Trading example, = this is=0Aa non issue because any reasonable person would run with TCP_NODE= LAY=0A(and possibly disable interrupt moderation), and optimize for latency= =0Aeven on a per flow basis.=0A=0AIn terms of coding effort, i suspect that= by replacing the 1-mtu=0Alimit (t_maxseg i believe is the variable that we= use in the SWS=0Aavoidance code) with 1-max-tso-segment we can probably ac= hieve good=0Aresults with little programming effort.=0A=0AThen the problem = remains that we should keep a copy of route and=0Aarp information in the so= cket instead of redoing the lookups on=0Aevery single transmission, as they= consume some 25% of the time of=0Aa sendto(), and probably even more when = it comes to large tcp=0Asegments, sendfile() and the like.=0A=0A=A0=A0=A0 c= heers=0A=A0=A0=A0 luigi=0A_______________________________________________= =0Afreebsd-net@freebsd.org mailing list=0Ahttp://lists.freebsd.org/mailman/= listinfo/freebsd-net=0ATo unsubscribe, send any mail to "freebsd-net-unsubs= cribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Aug 17 14:02:58 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ADFB76C8 for ; Sat, 17 Aug 2013 14:02:58 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm6.bullet.mail.ne1.yahoo.com (nm6.bullet.mail.ne1.yahoo.com [98.138.90.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 63D762974 for ; Sat, 17 Aug 2013 14:02:58 +0000 (UTC) Received: from [98.138.90.55] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 17 Aug 2013 14:02:51 -0000 Received: from [98.138.226.169] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 17 Aug 2013 14:02:51 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 17 Aug 2013 14:02:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 90697.13948.bm@omp1070.mail.ne1.yahoo.com Received: (qmail 75905 invoked by uid 60001); 17 Aug 2013 14:02:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1376748170; bh=glnQiP2oGzxd8FvuIRYGTRdMCngdPWXZKqDS2UPJgZM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cYAohvHRhZyh0shM7aMDrWATO9nZmpJpqPdB07dJf3iRH2UVnzawSfCc6HlqlQlXYnvsTY6qV3gQc4R5+BS/iNibHT83LeRb3vdmrj+WYbnn/xQVy4HFqG5zUEbdjz1cbwz1Uu4ghJfw6uAjMv0MA/qjkYSzqXVu6bVJTj1o1Sk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cCrJDb1PBu4Kix2JoX4m98HKLvXKFsistvSy6ft7/J5NJj6kqdC8oJi1uaq3SL1h3grofRMNANt7ZleFcYNI2p9h2x5RMXRAdHbckWobDkSctLcR4tE2vyv6OPmwtAzwOsaDK3ZdzQP/ym37NV8vxEpAK+QkIeGUCNcJAwqtGNY=; X-YMail-OSG: HAEoOZUVM1nJolpldzfg_wn1zLGimSrGvzGvsiL5xAyNnbo t1j0npDEroQfKtzVV23A2DgmKMv6x_5zBpmvd3CeH9vZPOiP3mkF3sCFfElA S4exVo6ZGWwkUzlNPX5b2r_vGR3gzQsQXU_jE4lTZnJhiaudXw5jf7EaV3iM 1_UKV6Fg.RaTJWOvC6P.qvPjgBvhys_h5O0yD8V2XDODfR3fhuV2kQDYpak6 oEQpmx50ulzsgEl82cZsUL1HLc9RNxbCUHRqMIVQj4sY0OWVKLn0WMfTskX4 BtZxGdUjUJibKMEcWkaE.SUHjlJbo_MV_OTVHbvZ.A80mwAiS6QCk8czBfVh Uxe1D.drKu8WdOFLz6.7Gvh8eoMjocpRuHfZ5Wvy1.VRrhTRPk7gM5Mk_b65 H3XsK3453bhXUWpLEIBC3uvu0NIb3g2LrCx4fRgVxYb7F9BBHjrTdMSYrIDq AWwM9FMQukmqGqIEG5cObv5NNieWCCgzZc3YtfFfRgdJnbetVJo5IPDVgeoV Wu_GPU3c0kPPLgO_b1S3mhWNP2tw_tOsYzn3cCdQPlMToKW8UA43nVVwhYYg fN_MXi96xLsUpApk1E91um5yfWKwD5YawahA3eVbN.xOk926nf2_0iBaKuoq QXQ.5VCIWysPQ7KuJ0zPTVHEHHVFD8RQaQqd6 Received: from [98.203.118.124] by web121601.mail.ne1.yahoo.com via HTTP; Sat, 17 Aug 2013 07:02:50 PDT X-Rocket-MIMEInfo: 002.001, Cgo.PkVGRklDSUVOQ1kgaXMgdGFudGFtb3VudC4gVGhyb3VnaHB1dCBpcyBhbG1vc3QgYWx3YXlzIGEgdHVuaW5nIGlzc3VlLgoKCk9mIGNvdXJzZSBJIG1lYW50IHBhcmFtb3VudC4gQ29mZmVlIG1hdHRlcnMgOi18CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpGcm9tOiBMdWlnaSBSaXp6byA8cml6em9AaWV0LnVuaXBpLml0PgpUbzogTGF3cmVuY2UgU3Rld2FydCA8bHN0ZXdhcnRAZnJlZWJzZC5vcmc.IApDYzogRnJlZUJTRCBOZXQgPG5ldEBmcmVlYnNkLm9yZz4gClNlbnQ6IFdlZG5lc2QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.154.571 References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> Message-ID: <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> Date: Sat, 17 Aug 2013 07:02:50 -0700 (PDT) From: Barney Cordoba Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) To: Luigi Rizzo , Lawrence Stewart In-Reply-To: <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Barney Cordoba List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 14:02:58 -0000 =0A=0A>>EFFICIENCY is tantamount. Throughput is almost always a tuning issu= e.=0A=0A=0AOf course I meant paramount. Coffee matters :-|=0A=0A___________= _____________________=0AFrom: Luigi Rizzo =0ATo: Lawren= ce Stewart =0ACc: FreeBSD Net =0AS= ent: Wednesday, August 14, 2013 6:21 AM=0ASubject: it's the output, not ack= coalescing (Re: TSO and FreeBSD vs Linux)=0A=0A=0AOn Wed, Aug 14, 2013 at = 05:23:02PM +1000, Lawrence Stewart wrote:=0A> On 08/14/13 16:33, Julian Eli= scher wrote:=0A> > On 8/14/13 11:39 AM, Lawrence Stewart wrote:=0A> >> On 0= 8/14/13 03:29, Julian Elischer wrote:=0A> >>> I have been tracking down a p= erformance embarrassment on AMAZON EC2 and=0A> >>> have found it I think.= =0A> >> Let us please avoid conflating performance with throughput. The=0A>= >> behaviour you go on to describe as a performance embarrassment is=0A> >= > actually a throughput difference, and the FreeBSD behaviour you're=0A> >>= describing is essentially sacrificing throughput and CPU cycles for=0A> >>= lower latency. That may not be a trade-off you like, but it is an=0A> >> i= mportant factor in this discussion.=0A...=0A> Sure, there's nothing wrong w= ith holding throughput up as a key=0A> performance metric for your use case= .=0A> =0A> I'm just trying to pre-empt a discussion that focuses on one met= ric and=0A> fails to consider the bigger picture.=0A...=0A> > I could see n= o latency reversion.=0A> =0A> You wouldn't because it would be practically = invisible in the sorts of=0A> tests/measurements you're doing. Our good fri= ends over at HRT on the=0A> other hand would be far more likely to care abo= ut latency on the order=0A> of microseconds. Again, the use case matters a = lot.=0A...=0A> > so, does "Software LRO" mean that LRO on hte NIC should be= ON or OFF to=0A> > see this?=0A> =0A> I think (check the driver code in qu= estion as I'm not sure) that if you=0A> "ifconfig lro" and the driver = has hardware support or has been made=0A> aware of our software implementat= ion, it should DTRT.=0A=0AThe "lower throughput than linux" that julian was= seeing is either=0Abecause of a slow (CPU-bound) sender or slow receiver. = Given that=0Athe FreeBSD tx path is quite expensive (redoing route and arp = lookups=0Aon every packet, etc.) I highly suspect the sender side is at fau= lt.=0A=0AAck coalescing, LRO, GRO are limited to the set of packets that yo= u=0Areceive in the same batch, which in turn is upper bounded by the=0Ainte= rrupt moderation delay. Apart from simple benchmarks with only=0Aa few flow= s, it is very hard that ack/lro/gro can coalesce more=0Athan a few segments= for the same flow.=0A=0A=A0=A0=A0 But the real fix is in tcp_output.=0A=0A= In fact, it has never been the case that an ack (single or coalesced)=0Atri= ggers an immediate transmission in the output path.=A0 We had this=0Ain the= past (Silly Window Syndrome) and there is code that avoids=0Asending less = than 1-mtu under appropriate conditions (there is more=0Adata to push out a= nyways, no NODELAY, there are outstanding acks,=0Athe window can open furth= er).=A0 In all these cases there is no=0Areasonable way to experience the d= ifference in terms of latency.=0A=0AIf one really cares, e.g. the High Spee= d Trading example, this is=0Aa non issue because any reasonable person woul= d run with TCP_NODELAY=0A(and possibly disable interrupt moderation), and o= ptimize for latency=0Aeven on a per flow basis.=0A=0AIn terms of coding eff= ort, i suspect that by replacing the 1-mtu=0Alimit (t_maxseg i believe is t= he variable that we use in the SWS=0Aavoidance code) with 1-max-tso-segment= we can probably achieve good=0Aresults with little programming effort.=0A= =0AThen the problem remains that we should keep a copy of route and=0Aarp i= nformation in the socket instead of redoing the lookups on=0Aevery single t= ransmission, as they consume some 25% of the time of=0Aa sendto(), and prob= ably even more when it comes to large tcp=0Asegments, sendfile() and the li= ke.=0A=0A=A0=A0=A0 cheers=0A=A0=A0=A0 luigi=0A_____________________________= __________________=0Afreebsd-net@freebsd.org mailing list=0Ahttp://lists.fr= eebsd.org/mailman/listinfo/freebsd-net=0ATo unsubscribe, send any mail to "= freebsd-net-unsubscribe@freebsd.org"=0A____________________________________= ___________=0Afreebsd-net@freebsd.org mailing list=0Ahttp://lists.freebsd.o= rg/mailman/listinfo/freebsd-net=0ATo unsubscribe, send any mail to "freebsd= -net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Aug 17 15:59:13 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EAEDA68E; Sat, 17 Aug 2013 15:59:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 572EB2DF6; Sat, 17 Aug 2013 15:59:13 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id hq12so1798317wib.2 for ; Sat, 17 Aug 2013 08:59:11 -0700 (PDT) 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=4I+nOnfALmRniMdZQhSS1ovi+DUx/8YLSalCAwwROUg=; b=fBfp9cArltjowzJrKD1Py8sWkLKcOJRV8sdX8/PYKHVdfAmJSNbymmDaj+91WTiH3n Xpov2vKxBJRyphyTq8SQt6W9G5b+DdDpx0m1bCXbV4F1MCeHJfZ59Ufym6KU+VEJNju+ 0F3sAtjZokMIGbmbsKwCOFFlySGm2GZtHCMIELQDdOp2lCWSUZ8cZB8b0oMPMQWj1kHG zv/xa+wh9c4lNvSLX2t2BAqDpU1/Q0/rySr9jZQ17+j9T9cFLx8N5toVxZYkzVQsug2I HNe+WerzHe28YpJXpKFrd3toIU/J88gnCy1PoA8BExJALAUXJgQ5uCiSTUVVrYGgSyXn Poog== MIME-Version: 1.0 X-Received: by 10.180.8.42 with SMTP id o10mr2210836wia.0.1376755151446; Sat, 17 Aug 2013 08:59:11 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Sat, 17 Aug 2013 08:59:11 -0700 (PDT) In-Reply-To: <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> Date: Sat, 17 Aug 2013 08:59:11 -0700 X-Google-Sender-Auth: 7NMZ5TjE9Ra2pKW0aU2cDmP-Pe8 Message-ID: Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) From: Adrian Chadd To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Lawrence Stewart , Luigi Rizzo , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Aug 2013 15:59:14 -0000 ... we get perfectly good throughput without 400k ints a second on the ixgbe driver. As in, I can easily saturate 2 x 10GE on ixgbe hardware with a handful of flows. That's not terribly difficult. However, there's a few interesting problems that need addressing: * There's lock contention between the transmit side from userland and the TCP timers, and the receive side with ACK processing. Under very high traffic load a lot of lock contention stalls things. We (the royal "we", I'm mostly just doing tooling at the moment) working on that. * There's lock contention on the ARP, routing table and PCB lookups. The latter will go away when we've finally implemented RSS for transmit and receive and then moved things over to using PCB groups on CPUs which have NIC driver threads bound to them. * There's increasing cache thrashing from a larger workload, causing the expensive lookups to be even more expensive. * All the list walks suck. We need to be batching things so we use CPU caches much more efficiently. The idea of using TSO on the transmit side and generic LRO on the receive side is to make the per-packet overhead less. I think we can be much more efficient in general in packet processing, but that's a big task. :-) So, using at least TSO is a big benefit if purely to avoid decomposing things into smaller mbufs and contending on those locks in a very big way. I'm working on PMC to make it easier to use to find these bottlenecks and make the code and data more efficient. Then, likely, I'll end up hacking on generic TSO/LRO, TX/RX RSS queue management and make the PCB group thing default on for SMP machines. I may even take a knife to some of the packet processing overhead. -adrian From owner-freebsd-net@FreeBSD.ORG Sat Aug 17 17:26:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5F6FB772 for ; Sat, 17 Aug 2013 17:26:56 +0000 (UTC) (envelope-from aurfalien@gmail.com) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B40D2240 for ; Sat, 17 Aug 2013 17:26:56 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h1so3545316oag.38 for ; Sat, 17 Aug 2013 10:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=VTaG2uLJxWt9Qg3LMtIJmgQ2CHW0DEzHUEJ3TH8A7ro=; b=dyb89L3Ch2cSbn7BD4/IZW//m/0Z2MKJehBZKgP/OkCf3q80vBy/UzOAKMWuEaWCmK WmRf8cfzWV/wyNFcp1Gey6I7EVYNrjI/CslhWBqrbWYkXNxZnYhqKvVqVrbQ0ijHAaLK kS1p7X5p6t/748V6qodiMqrCsEz+cNaMpSUx9mAI2fMUOfbOm60lNcCMlAQI9COvTvlj uadm5RO1AOV4SkanlP+rUxOye7OBY5WhX7Czbq0e9FXWhTDu5vlK3bAIhSi6F8nZqVwU 7D5GpYC1dHaI/Ba7mmlYiWLfVqD5HJTgXFUp/7RgkMCzPXANhUkVk/9l229QNfbYigkk PSCw== X-Received: by 10.60.45.65 with SMTP id k1mr1747227oem.48.1376760415461; Sat, 17 Aug 2013 10:26:55 -0700 (PDT) Received: from [192.168.1.74] (75-63-29-182.lightspeed.irvnca.sbcglobal.net. [75.63.29.182]) by mx.google.com with ESMTPSA id y1sm3303965oek.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 Aug 2013 10:26:54 -0700 (PDT) From: aurfalien Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Myrinet 10GB, odd log errors Date: Sat, 17 Aug 2013 10:26:51 -0700 Message-Id: To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Aug 2013 17:26:56 -0000 Hi all, I posted on the general list but felt that perhaps this one list is more = appropriate. First, my setup, FreeBSD 9.2RC1 Myrinet 10GB card w/jumbo enabled. myri_info tool spits out this info; pci-dev at 05:00.0 vendor:product(rev)=3D14c1:0008(00) behind bridge root-port: 00:03.0 8086:3c08 (x8.1/x16.3) Myri-10G-PCIE-8A -- Link x8 EEPROM String-spec: MAC=3D00:60:dd:45:73:23 SN=3D413665 PWR=3D100 PC=3D10G-PCIE-8A-R PN=3D09-03852 XFI=3DAEL1010 TAG=3Dze_tools-1_4_45 EEPROM MCP, PRESENT, length =3D 95812, crc=3D0x92df14e9 ETHZ::1.4.55b-ht2100 2012/03/06 22:14:18 self extracting = firmware Simple-bundle: exec_len =3D 95808 Running MCP: ETH ::1.4.55b-ht2100 -P- 2012/03/06 22:14:18 myri10ge netq = firmware loader,conf; if_mxge_load=3D"YES" I'm getting these messages every 10-15-20 min or so; Aug 17 09:55:22 prometheus kernel: mxge0: slice 0 struck? ring state: Aug 17 09:55:22 prometheus kernel: mxge0: tx.req=3D493367942 = tx.done=3D493367886, tx.queue_active=3D0 Aug 17 09:55:22 prometheus kernel: mxge0: tx.activate=3D0 = tx.deactivate=3D0 Aug 17 09:55:22 prometheus kernel: mxge0: pkt_done=3D370348316 = fw=3D370348339 Aug 17 09:55:22 prometheus kernel: mxge0: Watchdog reset! Aug 17 09:55:22 prometheus kernel: mxge0: NIC did not reboot, not = resetting And my performance is somewhat crappy, avg 100MB/s (Megabytes). Any insight? Thanks in advance, - aurf=