Re: [CFT] VMware vmxnet3 ethernet driver
- Original Message - Perhaps not, but they do support FreeBSD. I've started several support cases with FreeBSD-specific problems and they've fixed all so far. Yes, it is not a blackhole of support. At $JOB, we got caught by the FreeBSD specific issue of the busted timer that was fixed. But they've less helpful in other regards, and have more or less said FreeBSD isn't high in their priority because it isn't Linux. Are you aiming at completely replacing VMware tools, or just the device drivers? I'd like as much as possible to work out of the box. vmxnet3 is as far as my current interests go. OpenBSD has a vmt device that apparently does (at least the important bits of) what vmtoolsd does; I'll look at that closer at some point. I have no intention of preventing people from using VMware's tools if they desire, nor breaking existing users. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] VMware vmxnet3 ethernet driver
6 aug 2013 kl. 08:05 skrev Bryan Venteicher bry...@daemoninthecloset.org: - Original Message - Perhaps not, but they do support FreeBSD. I've started several support cases with FreeBSD-specific problems and they've fixed all so far. Yes, it is not a blackhole of support. At $JOB, we got caught by the FreeBSD specific issue of the busted timer that was fixed. But they've less helpful in other regards, and have more or less said FreeBSD isn't high in their priority because it isn't Linux. Are you aiming at completely replacing VMware tools, or just the device drivers? I'd like as much as possible to work out of the box. vmxnet3 is as far as my current interests go. OpenBSD has a vmt device that apparently does (at least the important bits of) what vmtoolsd does; I'll look at that closer at some point. Cool. I didn't know about vmt. I read the CVS log in the OpenBSD tree and it actually seems to do most of what I need. Having all this working out of the box (without VMware Tools installed) would be most welcome. …but I guess VMware would consider this an unsupported configuration or something like that, which sucks if/when I need to contact their support. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
CURRENT (r253984) buildworld fails: contrib/bind9/bin/dig/dighost.c:4340:27: error: passing 'const char *' to parameter of type 'void *' discards qualifiers
Buildword on r253984 fails ins BIND9: cc -O2 -pipe -O3 -march=native -I/usr/src/usr.sbin/pkg_install/create/../lib -pipe -O3 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wformat=2 -Wno-format-extra-args -Wno-format-nonliteral -Werror -c /usr/src/usr.sbin/pkg_install/create/perform.c --- usr.bin.all__D --- /usr/src/usr.bin/dig/../../contrib/bind9/bin/dig/dighost.c:4340:27: error: passing 'const char *' to parameter of type 'void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] isc_buffer_init(buffer, str, len); [...] signature.asc Description: PGP signature
[head tinderbox] failure on arm/arm
TB --- 2013-08-06 06:20:28 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-06 06:20:28 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-06 06:20:28 - starting HEAD tinderbox run for arm/arm TB --- 2013-08-06 06:20:28 - cleaning the object tree TB --- 2013-08-06 06:20:28 - /usr/local/bin/svn stat /src TB --- 2013-08-06 06:20:33 - At svn revision 253982 TB --- 2013-08-06 06:20:34 - building world TB --- 2013-08-06 06:20:34 - CROSS_BUILD_TESTING=YES TB --- 2013-08-06 06:20:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-06 06:20:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-06 06:20:34 - SRCCONF=/dev/null TB --- 2013-08-06 06:20:34 - TARGET=arm TB --- 2013-08-06 06:20:34 - TARGET_ARCH=arm TB --- 2013-08-06 06:20:34 - TZ=UTC TB --- 2013-08-06 06:20:34 - __MAKE_CONF=/dev/null TB --- 2013-08-06 06:20:34 - cd /src TB --- 2013-08-06 06:20:34 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Aug 6 06:20:41 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] rm -f .depend CC='cc ' mkdep -f .depend -a-DHAVE_ARC4RANDOM -DHAVE_POLL_H -DSMALL -DRESCUE -std=gnu99 /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsol.c /src/sbin/rtsol/../../usr.sbin/rtsold/if.c /src/sbin/rtsol/../../usr.sbin/rtsold/probe.c /src/sbin/rtsol/../../usr.sbin/rtsold/dump.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsock.c echo rtsol: /obj/arm.arm/src/tmp/usr/lib/libc.a .depend cc -O -pipe -DHAVE_ARC4RANDOM -DHAVE_POLL_H -DSMALL -DRESCUE -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c:193:25: error: shift count = width of type [-Werror,-Wshift-count-overflow] tm_max.tv_sec = ~(1UL (sizeof(tm_max.tv_sec) * 8 - 1)); ^ ~~~ 1 error generated. *** Error code 1 Stop. bmake[5]: stopped in /src/sbin/rtsol *** Error code 1 Stop. bmake[4]: stopped in /obj/arm.arm/src/rescue/rescue *** Error code 1 Stop. bmake[3]: stopped in /src/rescue/rescue *** Error code 1 Stop. bmake[2]: stopped in /src/rescue *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-06 09:06:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-06 09:06:47 - ERROR: failed to build world TB --- 2013-08-06 09:06:47 - 8011.84 user 1315.45 system 9979.10 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on armv6/arm
TB --- 2013-08-06 06:20:28 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-06 06:20:28 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-06 06:20:28 - starting HEAD tinderbox run for armv6/arm TB --- 2013-08-06 06:20:28 - cleaning the object tree TB --- 2013-08-06 06:20:28 - /usr/local/bin/svn stat /src TB --- 2013-08-06 06:20:33 - At svn revision 253982 TB --- 2013-08-06 06:20:34 - building world TB --- 2013-08-06 06:20:34 - CROSS_BUILD_TESTING=YES TB --- 2013-08-06 06:20:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-06 06:20:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-06 06:20:34 - SRCCONF=/dev/null TB --- 2013-08-06 06:20:34 - TARGET=arm TB --- 2013-08-06 06:20:34 - TARGET_ARCH=armv6 TB --- 2013-08-06 06:20:34 - TZ=UTC TB --- 2013-08-06 06:20:34 - __MAKE_CONF=/dev/null TB --- 2013-08-06 06:20:34 - cd /src TB --- 2013-08-06 06:20:34 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Aug 6 06:20:41 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] rm -f .depend CC='cc ' mkdep -f .depend -a-DHAVE_ARC4RANDOM -DHAVE_POLL_H -DSMALL -DRESCUE -std=gnu99 /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsol.c /src/sbin/rtsol/../../usr.sbin/rtsold/if.c /src/sbin/rtsol/../../usr.sbin/rtsold/probe.c /src/sbin/rtsol/../../usr.sbin/rtsold/dump.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsock.c echo rtsol: /obj/arm.armv6/src/tmp/usr/lib/libc.a .depend cc -O -pipe -DHAVE_ARC4RANDOM -DHAVE_POLL_H -DSMALL -DRESCUE -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c:193:25: error: shift count = width of type [-Werror,-Wshift-count-overflow] tm_max.tv_sec = ~(1UL (sizeof(tm_max.tv_sec) * 8 - 1)); ^ ~~~ 1 error generated. *** Error code 1 Stop. bmake[5]: stopped in /src/sbin/rtsol *** Error code 1 Stop. bmake[4]: stopped in /obj/arm.armv6/src/rescue/rescue *** Error code 1 Stop. bmake[3]: stopped in /src/rescue/rescue *** Error code 1 Stop. bmake[2]: stopped in /src/rescue *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-06 09:06:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-06 09:06:48 - ERROR: failed to build world TB --- 2013-08-06 09:06:48 - 8027.37 user 1315.12 system 9979.64 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic at USB drive plugging in
2013/7/24 下午10:26 於 Jia-Shiun Li jiash...@gmail.com 寫道： On Wed, Jul 24, 2013 at 4:02 AM, Alexander Motin m...@freebsd.org wrote: cam.k kernel module includes all existing periph drivers in one bundle. Loading cam.ko you are probably getting sg driver also, that triggers reported issue. You may try to rip out sg with single line hack to module's Makefile. The real fix require looking closer on sg, which I never used. Indeed. Test result did confirm that if sg is not included in cam.ko USB drives will not cause kernel to panic. Hi all, turns out, it may be conflicts between assumed and actual sg usage. The sg driver specifically assumes a write-read sequence. If a read comes first it will cause sg to panic at msleep() in sgread. In my case the process is hald-probe-storage tasting new devices. But it can be as simple as dd if=/dev/sgX. I am wondering that, is sg necessary on FreeBSD? Since most applications seem to live happily without it in GENERIC kernel. Maybe we can isolate it from cam.ko to make cam usable as module, and make the standalone sg module depending on cam module before sg got more resistant to misuse? Regards, Jia-Shiun. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on mips/mips
TB --- 2013-08-06 11:41:02 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-06 11:41:02 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-06 11:41:02 - starting HEAD tinderbox run for mips/mips TB --- 2013-08-06 11:41:02 - cleaning the object tree TB --- 2013-08-06 11:41:02 - /usr/local/bin/svn stat /src TB --- 2013-08-06 11:41:11 - At svn revision 253982 TB --- 2013-08-06 11:41:12 - building world TB --- 2013-08-06 11:41:12 - CROSS_BUILD_TESTING=YES TB --- 2013-08-06 11:41:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-06 11:41:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-06 11:41:12 - SRCCONF=/dev/null TB --- 2013-08-06 11:41:12 - TARGET=mips TB --- 2013-08-06 11:41:12 - TARGET_ARCH=mips TB --- 2013-08-06 11:41:12 - TZ=UTC TB --- 2013-08-06 11:41:12 - __MAKE_CONF=/dev/null TB --- 2013-08-06 11:41:12 - cd /src TB --- 2013-08-06 11:41:12 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Aug 6 11:41:19 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] (cd /src/rescue/rescue/../../sbin/rtsol /obj/src/make.amd64/bmake -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/rtsol/ depend /obj/src/make.amd64/bmake -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/rtsol/ rtsold.o rtsol.o if.o probe.o dump.o rtsock.o) rm -f .depend CC='cc ' mkdep -f .depend -a-DHAVE_ARC4RANDOM -DHAVE_POLL_H -DSMALL -DRESCUE -std=gnu99 /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsol.c /src/sbin/rtsol/../../usr.sbin/rtsold/if.c /src/sbin/rtsol/../../usr.sbin/rtsold/probe.c /src/sbin/rtsol/../../usr.sbin/rtsold/dump.c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsock.c echo rtsol: /obj/mips.mips/src/tmp/usr/lib/libc.a .depend cc -O -pipe -G0 -DHAVE_ARC4RANDOM -DHAVE_POLL_H -DSMALL -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c cc1: warnings being treated as errors /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c: In function 'main': /src/sbin/rtsol/../../usr.sbin/rtsold/rtsold.c:193: warning: left shift count = width of type *** Error code 1 Stop. bmake[5]: stopped in /src/sbin/rtsol *** Error code 1 Stop. bmake[4]: stopped in /obj/mips.mips/src/rescue/rescue *** Error code 1 Stop. bmake[3]: stopped in /src/rescue/rescue *** Error code 1 Stop. bmake[2]: stopped in /src/rescue *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-06 12:29:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-06 12:29:30 - ERROR: failed to build world TB --- 2013-08-06 12:29:30 - 2095.24 user 562.53 system 2908.23 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
weird patch(1) behavior
... Patching file using Plan A... Hunk #1 succeeded at 53 with fuzz 1 (offset -2 lines). patch: misordered hunks! output would be garbled But what I see is that patching actually fails. So: Hunk #1 succeeded is a lie, it did not succeed - target file was not changed at all. misordered hunks! is a lie, because the whole patch consisted of exactly one hunk. This was quite confusing. $ patch --version Patch version 2.1 gpatch worked as expected: patching file Hunk #1 FAILED at 55. 1 out of 1 hunk FAILED -- saving rejects to file .rej -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918
On Mon, Aug 5, 2013 at 10:53 PM, Gary Jennejohn gljennj...@googlemail.comwrote: On Mon, 5 Aug 2013 10:29:23 -0700 Craig Rodrigues rodr...@freebsd.org wrote: On the booted an running system, if you type: sysctl kern.conftxt that will display the actual kernel config options used to build the running kernel. Not necessarily sysctl kern.conftxt sysctl: unknown oid 'kern.conftxt': No such file or directory I forgot to mention, sysctl kern.conftxt will only display something if you have this in your kernel config: options INCLUDE_CONFIG_FILE # Include this file in kernel It's always handy to have that in your kernel config. -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918
I forgot to mention, sysctl kern.conftxt will only display something if you have this in your kernel config: options INCLUDE_CONFIG_FILE # Include this file in kernel It's always handy to have that in your kernel config. -- Craig No wonder why, it wasn't working for me and I didn't know why -- Sam Fourman Jr. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [net] protecting interfaces from races between control and data ?
On 05.08.2013 23:53, Luigi Rizzo wrote: On Mon, Aug 05, 2013 at 11:04:44PM +0200, Andre Oppermann wrote: On 05.08.2013 19:36, Luigi Rizzo wrote: ... [picking a post at random to reply in this thread] tell whether or not we should bail out). Ideally we don't want to have any locks in the RX and TX path at all. Ok i have read your proposal below but there are a few things I do not completely understand, below -- essentially I do not understand whether the removal of IFF_DRV_RUNNING (or equivalent) forces you to replace the ifp-new_tx_function() with something else when you want to do an ifconfig down Sorry, it's IFF_DRV_OACTIVE that'll go away, not IFF_DRV_RUNNING. It's of no use with multi-queue anyways. Though we may get more differentiated states for interface availability. Specifically, here are my doubts: - Considering that the rxq lock is rarely contended (only when the control path is active, which in your approach below requires killing and restarting the ithread), and is acquired/released only once per interrupt/batch, i am under the impression that the per-queue RX lock is not a performance problem and makes it easier to reason on the code (and does not require different approach for MSI-x and other cases). There are two important things here: 1) there must only be one (i)thread per RX queue to prevent lock contention; 2) even with a non-contended lock there are effects felt by the other cores or CPUs like bus lock cycles which are considerable. Stopping and restarting the ithread/taskqueue in those cases that require more involved (hardware) reconfiguration isn't much of an overhead compared to per-packet or per-packet-batch locking in the hot path. - in the tx datapath, do you want to acquire the txq lock before or after calling ifp-new_tx_function() ? (btw how it compares to ifp-if_start or ifp-if_transmit ?) Struct ifnet is going to be split into two parts, the stack owned part and the driver owned part. The stack will never fumble the driver owned parts and the driver must only change the stack owned parts through accessor functions. (This split has also been proposed by Juniper quite some time ago but for different reasons). The driver supplies a TX frame transmit function (mostly like if_transmit today) which does all locking and multi-queue handling internally (driver owned. This gives driver writers the freedom to better adjust to different hardware communication methods as they become available, like we witnessed a couple of times in the past. If the driver is multi-queue capable it takes the rss-hash from the packet header to select an appropriate queue which may have its own dedicated lock. If there is only one queue then it will obtain that lock which may see some contention when multiple cores try to send at the same time. The driver may do more extensive locking, however that likely comes at the expense of performance. Typically on modern NICs the TX function will be a thin locked wrapper around the DMA enqueue function. For or older or other kinds of interfaces it may implement full internal soft queuing (as the IFQ did). An efficient generic implementation of those will be provided for driver to make use of. If you do it within the tx handler then you lose the ability of replacing the handler when you do a reconfiguration, because grabbing the tx lock in the control path does not tell you whether anyone is in the handler. If you do it outside, then the driver should also expose the locks, or some locking function. The stack calls the transmit function without any driver-specific locks held. It'll make sure though that the stack-ifnet doesn't go away in between probably by using cheap rmlocks. The drivers control path gets a function to ensure that the stack has drained all writers and it is safe to reconfigure (as in callout_drain()). Not all hardware and control path changes necessarily require a reinitialization. The stack-ifnet shadows some information, like interface state, and may do its own independent SMP optimizations to avoid contention. Overall, it seems to me that keeping the IFF_DRV_RUNNING flag is a lot more practical, not to mention fewer modifications to the code. Generally we want to optimize for the fast packet path, reduce any friction we can, and take a hit on reconfig being more expensive as it is much less frequent. Mind you not all of this is worked out in detail yet and may be subject to further changes and refinements as more benchmarking of different approaches is performed. -- Andre [PS: I'm currently on summer vacation and write this while having access] [description of Andre's proposal below, for reference] cheers luigi Every queue has its own separate RX interrupt vector which is serviced by a single dedicated ithread (or taskqueue) which does while(1) for work on the RX ring only going to sleep when it reaches the end of work on the
Re: svn error during 'make buildkernel'?
On Sun, Aug 04, 2013 at 08:55:30PM -0400 I heard the voice of Glen Barber, and lo! it spake thus: The error generated is non-fatal, and once I receive response on a proposed patch, will be suppressed if the svn version used to check out the tree is not compatible with that used to check the version of the tree with the kernel build. But not try the ports svn as well? I mean, as breakage goes, it's not even in the top 100; I'd _much_ rather have a kernel that I have to guess the revision of but boots, than one properly recorded that doesn't. But it's still unpleasant, and is one of those things you probably won't notice missing until suddenly you need it. And this isn't just a presentism. Sure, right _now_ devel/subversion and base svnlite get along, but what happens when ports moves to 1.9 which changes the WT format? Even if -CURRENT src gets upgraded simultaneously[0], the same surely can't be said of every back branch. I realize this is all still a WIP, and please don't read any anger into my words. But this _has_ been something I've found a little worrisome since the original import/newvers change. Heck, newvers can show me version info if I'm getting my source tree from git or p4, but can't handle ports svn? By the time this works its way into a stable branch, I really think it should either handle svnversion from ports as well, or come with a big bright flashing warning that using svn from anything but base svnlite for /usr/src is a degraded experience. [0] Which still wouldn't really fix things, since /usr/bin/svnliteversion is arbitrarily old, not up to date with the source tree. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn error during 'make buildkernel'?
On Tue, Aug 06, 2013 at 01:11:07PM -0500, Matthew D. Fuller wrote: On Sun, Aug 04, 2013 at 08:55:30PM -0400 I heard the voice of Glen Barber, and lo! it spake thus: The error generated is non-fatal, and once I receive response on a proposed patch, will be suppressed if the svn version used to check out the tree is not compatible with that used to check the version of the tree with the kernel build. But not try the ports svn as well? I mean, as breakage goes, it's not even in the top 100; I'd _much_ rather have a kernel that I have to guess the revision of but boots, than one properly recorded that doesn't. But it's still unpleasant, and is one of those things you probably won't notice missing until suddenly you need it. And this isn't just a presentism. Sure, right _now_ devel/subversion and base svnlite get along, but what happens when ports moves to 1.9 which changes the WT format? Even if -CURRENT src gets upgraded simultaneously[0], the same surely can't be said of every back branch. I realize this is all still a WIP, and please don't read any anger into my words. But this _has_ been something I've found a little worrisome since the original import/newvers change. Heck, newvers can show me version info if I'm getting my source tree from git or p4, but can't handle ports svn? By the time this works its way into a stable branch, I really think it should either handle svnversion from ports as well, or come with a big bright flashing warning that using svn from anything but base svnlite for /usr/src is a degraded experience. [0] Which still wouldn't really fix things, since /usr/bin/svnliteversion is arbitrarily old, not up to date with the source tree. I have this on my todo list, but right now I have bigger things to deal with. As soon as I can, I will fix the logic. Right now, it is not as easy as checking which svn works, because the more I look at the logic for newvers.sh, the more I dislike how it all works. Glen pgpigOx_5HOhE.pgp Description: PGP signature
Re: [net] protecting interfaces from races between control and data ?
thanks for the explanations and for experimenting with the various alternatives. I started this thread just to understand whether something was already in place, and to make sure that what I do with netmap is not worse than the situation we have now. I guess that while the best solution comes out, a quick and non intrusive workaround is at least follow the approach that Bryan suggested. cheers luigi On Tue, Aug 6, 2013 at 6:43 PM, Andre Oppermann an...@freebsd.org wrote: On 05.08.2013 23:53, Luigi Rizzo wrote: On Mon, Aug 05, 2013 at 11:04:44PM +0200, Andre Oppermann wrote: On 05.08.2013 19:36, Luigi Rizzo wrote: ... [picking a post at random to reply in this thread] tell whether or not we should bail out). Ideally we don't want to have any locks in the RX and TX path at all. Ok i have read your proposal below but there are a few things I do not completely understand, below -- essentially I do not understand whether the removal of IFF_DRV_RUNNING (or equivalent) forces you to replace the ifp-new_tx_function() with something else when you want to do an ifconfig down Sorry, it's IFF_DRV_OACTIVE that'll go away, not IFF_DRV_RUNNING. It's of no use with multi-queue anyways. Though we may get more differentiated states for interface availability. Specifically, here are my doubts: - Considering that the rxq lock is rarely contended (only when the control path is active, which in your approach below requires killing and restarting the ithread), and is acquired/released only once per interrupt/batch, i am under the impression that the per-queue RX lock is not a performance problem and makes it easier to reason on the code (and does not require different approach for MSI-x and other cases). There are two important things here: 1) there must only be one (i)thread per RX queue to prevent lock contention; 2) even with a non-contended lock there are effects felt by the other cores or CPUs like bus lock cycles which are considerable. Stopping and restarting the ithread/taskqueue in those cases that require more involved (hardware) reconfiguration isn't much of an overhead compared to per-packet or per-packet-batch locking in the hot path. - in the tx datapath, do you want to acquire the txq lock before or after calling ifp-new_tx_function() ? (btw how it compares to ifp-if_start or ifp-if_transmit ?) Struct ifnet is going to be split into two parts, the stack owned part and the driver owned part. The stack will never fumble the driver owned parts and the driver must only change the stack owned parts through accessor functions. (This split has also been proposed by Juniper quite some time ago but for different reasons). The driver supplies a TX frame transmit function (mostly like if_transmit today) which does all locking and multi-queue handling internally (driver owned. This gives driver writers the freedom to better adjust to different hardware communication methods as they become available, like we witnessed a couple of times in the past. If the driver is multi-queue capable it takes the rss-hash from the packet header to select an appropriate queue which may have its own dedicated lock. If there is only one queue then it will obtain that lock which may see some contention when multiple cores try to send at the same time. The driver may do more extensive locking, however that likely comes at the expense of performance. Typically on modern NICs the TX function will be a thin locked wrapper around the DMA enqueue function. For or older or other kinds of interfaces it may implement full internal soft queuing (as the IFQ did). An efficient generic implementation of those will be provided for driver to make use of. If you do it within the tx handler then you lose the ability of replacing the handler when you do a reconfiguration, because grabbing the tx lock in the control path does not tell you whether anyone is in the handler. If you do it outside, then the driver should also expose the locks, or some locking function. The stack calls the transmit function without any driver-specific locks held. It'll make sure though that the stack-ifnet doesn't go away in between probably by using cheap rmlocks. The drivers control path gets a function to ensure that the stack has drained all writers and it is safe to reconfigure (as in callout_drain()). Not all hardware and control path changes necessarily require a reinitialization. The stack-ifnet shadows some information, like interface state, and may do its own independent SMP optimizations to avoid contention. Overall, it seems to me that keeping the IFF_DRV_RUNNING flag is a lot more practical, not to mention fewer modifications to the code. Generally we want to optimize for the fast packet path, reduce any friction we can, and take a hit on reconfig being more expensive as it is much less
