From owner-freebsd-hackers@freebsd.org Mon Sep 7 05:51:49 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 321719CBF4E for ; Mon, 7 Sep 2015 05:51:49 +0000 (UTC) (envelope-from noname.esst@yahoo.com) Received: from nm25-vm0.bullet.mail.ne1.yahoo.com (nm25-vm0.bullet.mail.ne1.yahoo.com [98.138.91.73]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F30631BB8 for ; Mon, 7 Sep 2015 05:51:48 +0000 (UTC) (envelope-from noname.esst@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441604956; bh=cX6xIiPTYHrOQK4PbYYojbP/t2XxKQFtw+/xjBqMYAU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=HuKWS+1qKH/dEFVC4uFQpd7gwBhRT0NC8Ma+veBV1cZM0GqcDK/jSR8dhoowDN82TtnHaOg7dMjze9u9NKRWDC/DVry4gotOqNh4BnykCQKy/Q69FQzzcIzM4N9/Y8Cw7blqdCM3Fp4wX3mrOm+DR87gx+nv16eedPve//qRpH5Txg0WRaPIZmeoyXMG0YB/BFghwLmo/QeTCulC+4CsJpne0NMFCDEJk8+QH3czU5Qy617M/KgBZWGFWsJoamW16uatd4MnnodylKE+QkdtUnUjKMhts00t258dFA7RcLO3t/1/xB6Dj2J1e67dzIiFLAH1RzJBUtkx4v2G+bX06A== Received: from [98.138.101.130] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 07 Sep 2015 05:49:16 -0000 Received: from [98.138.87.10] by tm18.bullet.mail.ne1.yahoo.com with NNFMP; 07 Sep 2015 05:49:16 -0000 Received: from [127.0.0.1] by omp1010.mail.ne1.yahoo.com with NNFMP; 07 Sep 2015 05:49:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 76964.30357.bm@omp1010.mail.ne1.yahoo.com X-YMail-OSG: XcUpE_gVM1lqyOv1ue9dk.I2LDXTHYeP1st6_9Z7QD1jva21Y5XazTNIO1oIvq6 Q8XpivviM25W6fTD37KA6Bn7teBWe6Bx7ZIgXewMdOzqZtBElVgYzypeJfa9Bb.pzvP8kYowfegB Vw4FWp8y7MJfLir07.hcE1APaRtp8QK1LxiRa.g8zoOQMVX6InonP0n0YrmXzLxS.pwN5SO_22bv soJUPwfgexEteuXhp8LkcroXBCUx.VZQpwLmsL81DLXNEp5lV_orimVp8Vwl1CkPpPMXUMdpEFmj HRLV2dGfu.DkyJ4PZBbUe8rVn7oBvmuNBpEPAsz5cVURhfZEetpMS.p7dkM0q.O09r3ZIZYx4sue 10CwtdHszy6zr.NVIjrDdfFwg1LAu6lb05k5rB2xj0FsjfffFlFkA.Q9uLSm45C7ztNiY0.cMsGp 6beNgf_7k_qaxZWuDQ1wAgjl0IdUi7v9zEu0c9gvXREENc7z3dnQiSEf4YYiBSoYkuCPs0HoixRG ip6mhEY8cwgQrFaFFZQ-- Received: by 98.138.105.219; Mon, 07 Sep 2015 05:49:15 +0000 Date: Mon, 7 Sep 2015 05:49:14 +0000 (UTC) From: Nomad Esst Reply-To: Nomad Esst To: Adrian Chadd Cc: Freebsd Hackers List Message-ID: <116728681.2558040.1441604954963.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: Subject: Re: em. igb performance test MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 05:51:49 -0000 Thank you Adrian.=C2=A0Do you have any ideas on how to add a buffer until t= he link is up? Regards.=20 On Sunday, September 6, 2015 7:08 PM, Adrian Chadd wrote: =20 =20 No, I meant you'd likely have to do that in order to get the functionality you desire! -a On 6 September 2015 at 01:40, Nomad Esst wrote: > Thank you all > We've recently found out that if we change the media type to 10BaseT all = ten > packets are arrived. And if we change the number of packets to 2 in > tcpreplay like > > tcpreplay -i gbeth0 -l 2 ospf_hello.pcap > > at least 1 packet is arrived at the time (while the media type is 10BaseT > and auto negotiation is disabled). but sometimes the second packet is > missed. > > Adrian, you said that someone is working on adding a buffer to queue the > packets until the interface come up. How can I contact with him/her? > > Regards. > > > > On Sunday, September 6, 2015 1:00 PM, Adrian Chadd > wrote: > > > > Hi, > > I can imagine someone hacking up driver support for buffering up to > 'n' packets until the link comes up, or timing them out if the link > doesn't come up in time. Thing is, bringing an interface up doesn't > guarantee it'll be up and live by the time the next command is run. > The cleanest way to get some clean behaviour here is to wait until the > link shows active before running the next command. > > hth, > > > -adrian > > > On 5 September 2015 at 22:24, Nomad Esst wrote: >> Thanks for your reply. How can I solve this problem? e.g. speed up the >> link >> negotiation, buffer the packets while link negotiation is being done ? A= ny >> ideas? >> >> Regards. >> >> >> >> On Saturday, September 5, 2015 8:01 PM, Adrian Chadd >> wrote: >> >> >> >> Hi, >> >> It's likely a combination of STP and how long it takes to do link >> negotiation. Packets transmitted during link negotiation will be lost. >> >> >> >> -adrian >> >> >> On 5 September 2015 at 08:03, Slawa Olhovchenkov wrote: >>> On Sat, Sep 05, 2015 at 02:45:28PM +0000, Nomad Esst via freebsd-hacker= s >>> wrote: >>> >>>> Hi allDuring some performance tests, we found out some weird problems. >>>> We >>>> use a shell script that do the following : >>>> do from 1 to 10Shutdown em/igb interfacesleep 3Bring em/igb interface >>>> uptcpreplay -i em0 -l ospf_hello.pcap sleep3end >>>> By running this shell on one side we expect 10 ospf hello packets to g= et >>>> arrived at the other side, but tcpdump (on the other side) shows 4, >>>> sometimes 8 and etc ... (not all 10 packets are arrived at the other >>>> side).We test this scenario with a Cisco router, and all packets are >>>> received at the Cisco side. What causes this packet loss in FreeBSD >>>> (maybe >>>> in em or igb drivers)?I know that this scenario may not have any use i= n >>>> the >>>> real world, but I'm curious, why Cisco don't have such behavior.Thanks >>>> in >>>> advance. >>> >>> uping interface not momentaly. >>> packets sending to down interface will be lost. >>> try to wait `status: active` before run tcpreplay. >>> Also, check STP off on interconnect switch you port. >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >> >> > > =20 From owner-freebsd-hackers@freebsd.org Mon Sep 7 10:45:03 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C4E99C8F94 for ; Mon, 7 Sep 2015 10:45:03 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.0x20.net", Issuer "mail.0x20.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1683E1BD6; Mon, 7 Sep 2015 10:45:02 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 842F26DF91B; Mon, 7 Sep 2015 12:44:59 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id t87AixWe092589; Mon, 7 Sep 2015 12:44:59 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id t87Aiwx3091508; Mon, 7 Sep 2015 12:44:58 +0200 (CEST) (envelope-from lars) Date: Mon, 7 Sep 2015 12:44:58 +0200 From: Lars Engels To: Pavel Timofeev Cc: Stefan Esser , freebsd-hackers@freebsd.org Subject: Re: How to control and setup service? Message-ID: <20150907104458.GL16003@e-new.0x20.net> References: <55DF261C.80009@freebsd.org> <20150827200534.GH16003@e-new.0x20.net> <55E086D3.1040700@freebsd.org> <55E1803E.7080706@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kkRamCq5m5VQq0L6" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Mon, 07 Sep 2015 11:29:33 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 10:45:03 -0000 --kkRamCq5m5VQq0L6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 31, 2015 at 10:57:27AM +0300, Pavel Timofeev wrote: > 2015-08-29 12:49 GMT+03:00 Stefan Esser : > > Am 28.08.2015 um 18:51 schrieb Pavel Timofeev: > >> Sorry for top posting! It's pretty hard to write email walking under > >> heavy rain and umbrella. > >> So, I talked about special key, not default behaviour. > >> Let me give you an example. > >> You got a server (or ten) which was/were somehow configured before you. > >> You want to reconfigure it/them. You don't care how and where it's > >> already configured, you just want to set particular rcvars and be sure > >> that no other rcvars are set. > >> > >> Before you came it was: > >> mysql_enable=3D"YES/NO" # no matter > >> mysql_datadir=3D"/mycozystorage/db/mysql" > >> mysql_defaults_extra_file=3D"/mycozystorage/mysql/my.cnf" > >> mysql_plugin_dir=3D"/somewhere/lib/mysql/plugin" > >> mysql_log_error=3D"/mycozystorage/db/mysql/hostname.err" > >> > >> then you run something like (look at -k key) > >> # service -k mysql-server enable set datadir "/mysqldb" log_error > >> "/mysqllogs/hostname.err" > >> it becomes > >> mysql_enable=3D"YES" > >> mysql_datadir=3D"/mysqldb" > >> mysql_log_error=3D"/mysqllogs/hostname.err" > >> > >> I. e. sets what requested and deletes rcvars which was not requested. > > > > I think that the removal of the previous config state should not come > > as the side-effect of some "set" command. > > > > I'd rather introduce a now verb for this purpose, which has the effect > > of clearing all previous settings for a service, instead of overloading > > the "set" operation. >=20 > BTW, it's already suggested here https://reviews.freebsd.org/D451 > it's rcdelete. Not sure if it's good name. >=20 Back from holidays... It would be nice if we could find a consensus what should be done with my patch in D451. The code itself works fine for me, but what's still unclear is what config files should be touched by it: 1 /etc/rc.conf 2 /etc/rc.conf.local 3 /etc/rc.conf.d/$servicename I could add some flags to service(8), e.g. -l to edit rc.conf.local, -d for /etc/rc.conf.d. But please don't let the review rot any longer. :) --kkRamCq5m5VQq0L6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJV7WqqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1t5hsH/3HBSlGFYgxcO6R9jC06Etoq /RVkrA87XyKNQTstH0UVkEZl5Pvc8CI6veYRvEmuVwI18FmF9UW6H7wUOEQTKoJN b/EzB3w3QCG5hNp1jv22SG0gpDiIpFTV7TxtUDbEjdUWa5YbzE3u96xlJ2ZsxPAl Ls5Sx/zphW+pe/L5E66gkETn0g5aJmeB6GJYWkE0uuWo9dZIcbAz+p3qzwwLsuC1 zJQHASsGMxd0xItWzg+47sd4TkQbQTud9U3ZbOdY1TMvvkjWShMz4vCQ/yH5aQPL WkpO5qZlUdb+xPlhcigqm/0C9cwiKgSZ5dM3pmJwJUMC2Z3bycO4VyCzhmbBhlA= =5JJL -----END PGP SIGNATURE----- --kkRamCq5m5VQq0L6--