Re: 回复： pow function in kernel space
On Fri, Jun 20, 2014 at 08:59:49AM +0800, 张晗 wrote: > Hi: > > I am doing a research on D2TCP(http://dl.acm.org/citation.cfm?id=2342388), I > just want to implement it into the linux kernel. When calculating the penalty > function, it is p = a^d, where 0< a < 1 and 0< d < 1. Since the kernel only > offers integer, so in my code, so I let a multiply 2^10. But I have no idea > of calculating a^d when 0< d < 1. May be I want a approximate algorithm or > other methods. Can you help me ? > thanks~ > First of all this is a FreeBSD list and FreeBSD is not Linux. It is possible to use FPU in kernel mode, but it requires some additional work. Both FreeBSD and Linux kernels provide functions for this purpose, see kernel_fpu_begin and kernel_fpu_end on Linux. I suggest you send further questions to some Linux-related resource, although I can't recommend any in particular. -- Mateusz Guzik ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: LOR in rtsock/ifnet
On Mon, Nov 26, 2012 at 04:48:09PM +0900, Hiroki Sato wrote: > Rui Paulo wrote > in <63c19ad8-ea8d-49a8-9e98-4235c4745...@freebsd.org>: > > rp> On 25 Nov 2012, at 23:35, Adrian Chadd wrote: > rp> > rp> > DO we know which commit triggered this? > rp> > rp> > rp> I haven't bisected. > > I do not think my commit triggered it because it occurred in > rt_msg2(). Andrey, can you take a look at this? > I'm booting i386 on VirtualBox and I have two em interfaces, em0 is configured to get ip from DHCP and the other one is untouched. I don't get this lor with r243186, but I see it with r243187. I'm happy to provide more information if needed. -- Mateusz Guzik ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: LOR in rtsock/ifnet
On Fri, Nov 30, 2012 at 11:16:25PM -0800, Adrian Chadd wrote: > Mateusz: are you sure it's that commit? > Yes, I double-checked right now. > I still get this in -HEAD: > Maybe I expressed myself incorrectly, I meant to say that LOR started showing up since r243187. The code is still in head and no fixes were comitted (that I know of at least), so I guess that you seeing this LOR on head is expected. :) > > On 26 November 2012 10:26, Mateusz Guzik wrote: > > On Mon, Nov 26, 2012 at 04:48:09PM +0900, Hiroki Sato wrote: > >> Rui Paulo wrote > >> in <63c19ad8-ea8d-49a8-9e98-4235c4745...@freebsd.org>: > >> > >> rp> On 25 Nov 2012, at 23:35, Adrian Chadd wrote: > >> rp> > >> rp> > DO we know which commit triggered this? > >> rp> > >> rp> > >> rp> I haven't bisected. > >> > >> I do not think my commit triggered it because it occurred in > >> rt_msg2(). Andrey, can you take a look at this? > >> > > > > I'm booting i386 on VirtualBox and I have two em interfaces, em0 is > > configured to get ip from DHCP and the other one is untouched. > > > > I don't get this lor with r243186, but I see it with r243187. > > > > I'm happy to provide more information if needed. > > -- > > Mateusz Guzik -- Mateusz Guzik ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: LOR in rtsock/ifnet
On Sun, Dec 02, 2012 at 06:54:36AM +0900, Hiroki Sato wrote: > Hiroki Sato wrote > in <20121201.225004.2232262673795057435@allbsd.org>: > > hr> Mateusz Guzik wrote > hr> in <20121201133609.ga5...@dft-labs.eu>: > hr> > hr> mj> On Fri, Nov 30, 2012 at 11:16:25PM -0800, Adrian Chadd wrote: > hr> mj> > Mateusz: are you sure it's that commit? > hr> mj> > > hr> mj> > hr> mj> Yes, I double-checked right now. > hr> mj> > hr> mj> > I still get this in -HEAD: > hr> mj> > > hr> mj> > hr> mj> Maybe I expressed myself incorrectly, I meant to say that LOR started > hr> mj> showing up since r243187. > hr> mj> > hr> mj> The code is still in head and no fixes were comitted (that I know of > at > hr> mj> least), so I guess that you seeing this LOR on head is expected. :) > hr> > hr> Thanks for the info. I am investigating this now. > > Can anyone test the attached patch and let me know if the LOR > persists or not? > I got the following build failure: /srv/repos/freebsd/sys/netinet6/in6_cksum.c:69:22: error: sys/vnet.h: No such file or directory In file included from /srv/repos/freebsd/sys/netinet6/in6_cksum.c:72: /srv/repos/freebsd/sys/netinet6/scope6_var.h:45: error: expected declaration specifiers or '...' before 'deembed_scopeid' cc1: warnings being treated as errors /srv/repos/freebsd/sys/netinet6/scope6_var.h:45: warning: data definition has no type or storage class /srv/repos/freebsd/sys/netinet6/scope6_var.h:45: warning: type defaults to 'int' in declaration of 'VNET_DECLARE' However after changing sys/vnet.h to net/vnet.h the kernel compiled fine and LOR is gone. -- Mateusz Guzik ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: MAC cloning available like Linux has?
On Fri, Dec 14, 2012 at 02:46:33PM -0800, Chris H wrote: > > On Fri, Dec 14, 2012 at 12:11 PM, Chris H wrote: > > > >> > Greetings, > >> > I attempted another BSD install on another piece of hardware the > >> > other day. I'm evaluating a different ISP, and the gateway/router/modem > >> > they provided, has 1 ether, which I currently use on my server, and 1 > >> > USB(3) port that I had intended to use with the new install. Problem I > >> > ran into, was that BSD generates random (fake) MAC(3) addresses, when > >> > utilizing the CDCE(4)/ue0. This worked just fine during the install. > >> > But the modem "held" the MAC(3) generated during the install, and I > >> > now have no idea how to tell BSD to use that MAC(3) when negotiating > >> > with the modem. I had absolutely no difficulty assigning the MAC(3) > >> > address when spinning up several "live" Linux distro(s) -- they provide > >> > the following: > >> > su > >> > password: *** > >> > ifconfig eth1 down > >> > ifconfig eth0 hw ether ##:##:##:##:##:## > >> > dhclient eth0 > >> > blah, blah, blah > >> EDIT > >> those _should_ have all read "eth1" in the session quoted above. > >> Sorry. > >> > > >> > And I'm connected. > >> > Couldn't manage that with BSD. What must I do? Is it even possible? > >> > If so, can it be assigned for use on a permanent basis? > >> > > >> > Thank you for all your time, and consideration. > >> > >> > > http://lmgtfy.com/?q=freebsd+change+mac+address > > Further internet searches provided useless, incorrect information. > So, just for kicks, I spun up, and installed a copy PC-BSD-9. > The LXDE desktop provided a network applet that allowed to use > the hardware MAC(3), or one of my choosing. I chose my own. > But even that failed. So I attempted to use: > > # ifconfig ue0 ether ##:##:##:##:##:## > # ifconfig ue0 > ether ##:##:##:##:##:## > # dhclient ue0 > blah, blah, blah > # ping yahoo.com > 64 bytes from 98.138.253.109: icmp_seq=0 ttl=53 time=48.867 ms > 64 bytes from 98.138.253.109: icmp_seq=1 ttl=53 time=51.118 ms > 64 bytes from 98.138.253.109: icmp_seq=2 ttl=53 time=80.145 ms > 64 bytes from 98.138.253.109: icmp_seq=3 ttl=53 time=48.964 ms > > OK. So it is possible with BSD. Let's try to make it permanent! > adding any of the following attempts failed miserably: > ifconfig_ue0="ether ##:##:##:##:##:## DHCP" > > ifconfig_ue0="DHCP" > ifconfig_ue0_alias0="ether ##:##:##:##:##:##" > > So apparently it's not possible (for me) to accomplish this > with anything but Linux. Bummer, have used BSD exclusively > since the early 80's. Couldn't imagine having to use anything > else. :( > > ifconfig_ue0="ether ##:##:##:##:##:##; DHCP" -- Mateusz Guzik ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/135067: [patch] [fib] Incorrect KASSERTs in sys/net/route.c
The following reply was made to PR kern/135067; it has been noted by GNATS. From: Mateusz Guzik To: bug-follo...@freebsd.org Cc: Subject: Re: kern/135067: [patch] [fib] Incorrect KASSERTs in sys/net/route.c Date: Thu, 21 Jan 2010 21:06:09 + Hi, this PR can be closed as it originated from my mistake. Again, sorry for the noise -- Mateusz Guzik ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/135067: [patch] [fib] Incorrect KASSERTs in sys/net/route.c
The following reply was made to PR kern/135067; it has been noted by GNATS. From: Mateusz Guzik To: Julian Elischer Cc: bug-follo...@freebsd.org Subject: Re: kern/135067: [patch] [fib] Incorrect KASSERTs in sys/net/route.c Date: Sat, 30 May 2009 10:42:25 +0200 On Sat, May 30, 2009 at 3:58 AM, Julian Elischer wrot= e: > if you have 16 fibs then valid values are 0,1,2,.14,15 > > if fibnum =3D=3D rt_numfibs then that is an error. > > thus in setfib... if uap->numfbs is 16 OR GREATER =A0it is and EINVAL > > and the kasserts in route.c need to check that fibnum is =A0LESS THAN > rt_numfibs. > That's correct. > > what makes you think there is an error? > I somehow misread that KASSERT as triggered only when fibnum > rt_numfibs. I guess it was too late at night. :) Sorry for the noise. -- Mateusz Guzik ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
nd6_timer vs Giant vs locking in general
Hello there, dtrace revealed that the kernel schedules nd6_timer a lot. Not only that, his callout is not mpsafe so the kernel locks Giant which I believe is an oversight. Also the code looks really suspicious as it walks V_in6_ifaddrhead without any locking (not to mention there is an interestng comment: XXXRW: in6_ifaddrhead locking :>) Dropping it here in case there is someone interested in fixing this up. -- Mateusz Guzik ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Unable to kill a non-zombie process with -9
ags=) at /usr/src/sys/kern/sched_ule.c:1962 > #1 0x808b8c1e in mi_switch (flags=266, newtd=0x0) at > /usr/src/sys/kern/kern_synch.c:494 > #2 0x808c04b0 in thread_suspend_switch > (td=0xf802c061f490) at /usr/src/sys/kern/kern_thread.c:883 > #3 0x808c0276 in thread_single (mode=1) at > /usr/src/sys/kern/kern_thread.c:713 > #4 0x8087c1bb in exit1 (td=0xf802c061f490, rv=9) at > /usr/src/sys/kern/kern_exit.c:180 > #5 0x808b2faf in sigexit (td=, > sig=) at /usr/src/sys/kern/kern_sig.c:2935 > #6 0x808b3669 in postsig (sig=) at > /usr/src/sys/kern/kern_sig.c:2822 > #7 0x808f6f57 in ast (framep=) at > /usr/src/sys/kern/subr_trap.c:271 > #8 0x80c75870 in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:416 > #9 0x000801d6f19a in ?? () > Previous frame inner to this frame (corrupt stack?) > > > thread 371 > [Switching to thread 371 (Thread 100598)]#0 sched_switch > (td=0xf80221857000, newtd=, flags= optimized out>) at /usr/src/sys/kern/sched_ule.c:1962 > 1962in /usr/src/sys/kern/sched_ule.c > bt > #0 sched_switch (td=0xf80221857000, newtd=, > flags=) at /usr/src/sys/kern/sched_ule.c:1962 > #1 0x808b8c1e in mi_switch (flags=260, newtd=0x0) at > /usr/src/sys/kern/kern_synch.c:494 > #2 0x808f2e3a in sleepq_wait (wchan=0x0, pri=0) at > /usr/src/sys/kern/subr_sleepqueue.c:620 > #3 0x80864aad in _cv_wait (cvp=0x8147a500, > lock=0x8147a480) at /usr/src/sys/kern/kern_condvar.c:139 Here your thread got blocked trying to acquire a mutex. You can find the owner by inspecting vm (vm=0x8147a480) -> vm_lock -> mtx_lock. You may need to cast along the way. Roughly speaking (untested): f 4 p (struct vmem *)0x8147a480)->vm_lock->mtx_lock > #4 0x808fb05f in vmem_xalloc (vm=0x8147a480, > size0=, align=, phase=0, > nocross=, minaddr=0, > maxaddr=18446735286768857088, flags=8194, addrp= out>) at /usr/src/sys/kern/subr_vmem.c:1196 > #5 0x808fae6b in vmem_alloc (vm=0x0, size=0, flags= optimized out>, addrp=0xfe0466e1d6e8) at > /usr/src/sys/kern/subr_vmem.c:1082 > #6 0x80b0fa58 in kmem_malloc (vmem=0x8147a480, > size=2139729920, flags=2) at /usr/src/sys/vm/vm_kern.c:314 > #7 0x80b08dfb in uma_large_malloc (size= out>, wait=2) at /usr/src/sys/vm/uma_core.c:1006 > #8 0x80898cf3 in malloc (size=2139729920, > mtp=0x813a0450, flags=0) at > /usr/src/sys/kern/kern_malloc.c:520 > #9 0x8096307b in bpf_buffer_ioctl_sblen > (d=0xf80159ea9000, i=) at > /usr/src/sys/net/bpf_buffer.c:183 > #10 0x80960a3c in bpfioctl (dev=0x0, cmd= out>, addr=0xf801fbd06b40 "", flags=0, td=0xf80221857000) at > /usr/src/sys/net/bpf.c:408 > #11 0x807ac1df in devfs_ioctl_f (fp=0xf8002b3d9d20, > com=3221504614, data=0xf801fbd06b40, cred=, > td=0xf80221857000) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 > #12 0x808fdfae in kern_ioctl (td=0xf80221857000, > fd=, com=0) at file.h:319 > #13 0x808fdd2f in sys_ioctl (td=0xf80221857000, > uap=0xfe0466e1da40) at /usr/src/sys/kern/sys_generic.c:702 > #14 0x80c8f117 in amd64_syscall (td=0xf80221857000, > traced=0) at subr_syscall.c:134 > #15 0x80c7580b in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:391 > #16 0x000801d8f08a in ?? () > Previous frame inner to this frame (corrupt stack?) > > -- Mateusz Guzik ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: about that DFBSD performance test
On Wed, Mar 08, 2017 at 03:57:10PM +0300, Slawa Olhovchenkov wrote: > On Wed, Mar 08, 2017 at 05:25:57AM -0700, Kevin Bowling wrote: > > > Right off the bat, FreeBSD doesn't really understand NUMA in any sufficient > > capacity. Unfortunately at companies like the one I work at, we take that > > to mean "OK buy a high bin CPU and only populate one socket" which serves > > NUMA applicable only to high-localy computed tasks. > http/https/any_network_related serving is not related to this. > Indeed, on modern CPU is not important to bind NIC irq handlers to > same CPU/sockets as NIC. > Well, for both benchmarks this is both true and false. First and foremost there is general kernel scalability. Certain counters and most locks are purely managed with atomic operations. An atomic operation grabs the entire cacheline with the particular variable (64 bytes in total) in exclusive mode. If you have to do an atomic operation you are somewhat slower than you be otherwise. If you have to do an atomic operation and another cpu has the cacheline, you are visibly slower. And if the cacheline travels a lot between cpus (e.g. because the lock is contended), the performance degrades rapidly. NUMA increases the cost of cacheline bounces, making the already bad situation even worse. Locking primitives are affected by NUMA significantly more than they have to be (I'm working on that), but any fixes in the area are just bandaids. For instancee, I reproduce the http benchmark and indeed I have about 75k req/s on 2 * 10 * 2 box, although I'm only using one client. Profiling shows excessive contention on the 'accept lock' and something else from the socket layer. The latter comes from kqueue being extremely inefficient by acquiring and releasing the same lock about 4 times per call on average (if it took it *once* it would significantly reduce lock bouncing around, including across the socket to a different node). But even taking it once is likely too bad - no matter how realistically fast this can get, if all nginx processes serialize on this lock this is not going to scale. That said, the end result would be significantly higher if lock granularity was better and I suspect numa-awareness would not be a significant factor in the http benchmark - provided locks are granular enough, they would travel across the socket only if they get pushed out of the cache (which would be rare), but there would be no contention. This is a small excerpt from a reply I intend to write to the other thread where the 'solisten' patch is discussed. It gets rid of the accept lock contention, but this increases the load on other lock and thattemporarily slows things down. -- Mateusz Guzik ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ip(8) in base
If you are not going to be compatible, use a different name. I don't have good ideas, but something in the lines of "netctl" or similar should do the trick. On 8/16/20, Alexander V. Chernikov wrote: > I want to introduce ip(8) or something similar in base. > Basically, I need some userland tool to explicitly operates on nexthops, > nexthop groups and fib lookup algorithms. > > The existing tools are not well suited for the job: route(8) may be a > candidate, but (a) it would either add another bunch of options or > drastically change the tool by introducing [route nhop add], [route nhgroup > add] and (b) listing is traditionally done by netstat(8). > > I feel like there is a need of some cli tool that provides the ability to > easily extend it by having separate namespaces for each sub-command (hello, > ifconfig). > > Naming is hard. I can, for example, use "rt" as a name to address my use > cases. > However, given the kernel interfaces for managing nexthops/nexhop groups are > the same as with routes/arp/ndp, why not spending some additional time and > support operating on routes and neighbors and name it ip? > > Though, that arises multiple questions. > Are we comfortable with ip(8) as a name in general? > If we are, what’s our take on having the compatible interface with Linux > ip(8)? > > Any comments/feedback is welcome :-) > > > Appendix > List of commands I need implemented > > cmd [-46m] nhop create [gw XX] [iface YYY] [mtu YYY] [reject] [proxyfib Y] > [fib X][ipv4] [ipv6] > cmd [-46m] nhop delete nhop_id > cmd -46m nhop list > cmd -j nhop list # json > > cmd -46m nhgroup create nhops 1,2,3,4,5,6 [fib X] > cmd -46 nhgroup create nhops 1=100,2=100,3=200,4=100 [proxyfib Y][fib X] > cmd -46 nhroup list > cmd -46 nhgroup delete nhgroup_id > > cmd -46 fib algo list > cmd -46 fib algo set algo dpdk_lpm6 fib 0 > cmd -46 fib algo set algo auto fib 0 > > > /Alexander > ___ > freebsd-hack...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > -- Mateusz Guzik ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
