Netmap. Example to understand?
Hello I have three boxes running linux or freebsd. A is a loadbalancer to b and c. Same network. A has three nics: one for internet, one connected with B and one connected with C to avoid another switch for a small configuration. I wish to understand how netmap can help me saturating a 10Gbit link with a i7 3930k (could be replaced by something less powerful if netmap allow big perf jump). How can i select the nic to which i wish to send the packet? The read write pattern is not clear to me. Will netfilter be completely bypassed hence achieving high perf? I am in need for an example mates. Thanks a lot Bye ___ 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: Netmap. Example to understand?
Ok got it! https://github.com/fichtner/netmap/blob/master/examples/bridge.c > From: deco33...@hotmail.com > To: freebsd-net@freebsd.org > Subject: Netmap. Example to understand? > Date: Thu, 9 Oct 2014 10:05:56 +0200 > > Hello > > I have three boxes running linux or freebsd. > > A is a loadbalancer to b and c. Same network. > A has three nics: one for internet, one connected with B and one connected > with C to avoid another switch for a small configuration. > > I wish to understand how netmap can help me saturating a 10Gbit link with a > i7 3930k (could be replaced by something less powerful if netmap allow big > perf jump). > > How can i select the nic to which i wish to send the packet? The read write > pattern is not clear to me. Will netfilter be completely bypassed hence > achieving high perf? > I am in need for an example mates. > Thanks a lot > Bye > > ___ > 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" ___ 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: HEADS UP: Merging projects/ipfw to HEAD
On 04 Oct 2014, at 16:35, Alexander V. Chernikov wrote: > Hi, > > I'm going to merge projects/ipfw branch to HEAD in the middle of next week. Merged in r 272840. > > What has changed: > > Main user-visible changes are related to tables: > > * Tables are now identified by names, not numbers. There can be up to 65k > tables with up to 63-byte long names. > * Tables are now set-aware (default off), so you can switch/move them > atomically with rules. > * More functionality is supported (swap, lock, limits, user-level lookup, > batched add/del) by generic table code. > * New table types are added (flow) so you can match multiple packet fields at > once. > * Ability to add different type of lookup algorithms for particular table > type has been added. > * New table algorithms are added (cidr:hash, iface:array, number:array and > flow:hash) to make certain types of lookup more effective. > * Table value are now capable of holding multiple data fields for different > tablearg users > > Some examples (see ipfw(8) manual page for the description): > > 0:02 [2] zfscurr0# ipfw table fl2 create type flow:src-ip,proto,dst-port > algo flow:hash valtype skipto,fib > 0:02 [2] zfscurr0# ipfw table fl2 info > +++ table(fl2), set(0) +++ >kindex: 0, type: flow:src-ip,proto,dst-port >valtype: number, references: 0 >algorithm: flow:hash >items: 0, size: 280 > 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 > 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 > 0:02 [2] zfscurr0# ipfw table fl2 list > +++ table(fl2), set(0) +++ > 2a02:6b8::333,6,443 45000 > 10.0.0.92,6,80 22000 > 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 flow > 'table(fl2)' > > ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" > ipfw table mi_test add 10.0.0.8/30 > ipfw table mi_test add 2a02:6b8:b010::1/64 25 > > # ipfw table si add 1.1.1.1/32 2.2.2.2/32 > added: 1.1.1.1/32 > added: 2.2.2.2/32 > # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 > exists: 2.2.2.2/32 2200 > added: 4.4.4.4/32 > ipfw: Adding record failed: record already exists > ^ Returns error but keeps inserted items > # ipfw table si list > +++ table(si), set(0) +++ > 1.1.1.1/32 > 2.2.2.2/32 > 4.4.4.4/32 > # ipfw table si atomic add 3.3.3.3/32 4.4.4.4/32 4400 5.5.5.5/32 > added(reverted): 3.3.3.3/32 > exists: 4.4.4.4/32 4400 > ignored: 5.5.5.5/32 > ipfw: Adding record failed: record already exists > ^ Returns error and reverts added records > > Performance changes: > * Main ipfw lock was converted to rmlock > * Rule counters were separated from rule itself and made per-cpu. > * Radix table entries fits into 128 bytes > * struct ip_fw is now more compact so more rules will fit into 64 bytes > * interface tables uses array of existing ifindexes for faster match > > ABI changes: > All functionality supported by old ipfw(8) remains functional. Old & new > binaries can work together with the following restrictions: > * Tables named other than ^\d+$ are shown as table(65535) in ruleset in old > binaries > * I'm a bit unsure about "lookup src-port|dst-port N" case, something may be > broken here. Anyway, this can be fixed for MFC > > Internal changes:. > Changing table ids to numbers resulted in format modification for most > sockopt codes. > Old sopt format was compact, but very hard to extend (no versioning, > inability to add more opcodes), so > * All relevant opcodes were converted to TLV-based versioned IP_FW3-based > codes. > * The remaining opcodes were also converted to be able to eliminate all older > opcodes at once > * All IP_FW3 handlers uses special API instead of calling sooptcopy* directly > to ease adding another communication methods > * struct ip_fw is now different for kernel and userland > * tablearg value has been changed to 0 to ease future extensions > * table "values" are now indexes in special value array which holds extended > data for given index > * Batched add/delete has been added to tables code > * Most changes has been done to permit batched rule addition. > * interface tracking API has been added (started on demand) to permit > effective interface tables operations > * O(1) skipto cache, currently turned off by default at compile-time (eats > 512K). > > * Several steps has been made towards making libipfw: > * most of new functions were separated into "parse/prepare/show and > actuall-do-stuff" pieces (already merged). > * there are separate functions for parsing text string into "struct ip_fw" > and printing "struct ip_fw" to supplied buffer (already merged). > * Probably some more less significant/forgotten features > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-ne
Re: ixgbe(4) spin lock held too long
On Wed, Oct 8, 2014 at 12:29 PM, John Baldwin wrote: > My only other thought is if a direct timeout routine ran for a long time. > > I just committed a change to current that can let you capture KTR traces of > callout routines for use with schedgraph (r272757). Unfortunately, > enabling KTR_SCHED can be slow. If you are up for trying it, I do think > that > building a kernel with KTR and KTR_SCHED enabled (KTR_COMPILE=KTR_SCHED and > KTR_MASK=KTR_SCHED) with the kernel part of the commit I referenced above > applied is the best bet to figure out why it is spinning so long. If you > can > try that (and if it doesn't slow things down too much) and get a panic with > those options enabled, then capture the output of > 'ktrdump -e /path/to/kernel -m /var/crash/vmcore.X -ct', we can use > Src/tools/sched/schedgraph.py to look at that output to get a picture of > what > was going on just prior to the crash. > > -- > John Baldwin > As luck would have it.. caught one of the boxes with the new KTR code/options after only an hour. Crashed in the same way w tid 13 and looking the same in callout_process spin lock 0x81262d00 (callout) held by 0xf800151fe000 (tid 13) too long spin lock 0x81262d00 (callout) held by 0xf800151fe000 (tid 13) too long #4 0x8070d6fa in callout_process (now=7915682202423) at /usr/src/sys/kern/kern_ timeout.c:490 The ktrdump oddly only seems to have the last 702, though debug.ktr.entries is set to 1024. It appears the buffer may also start after 13 had already hung? I've bumped debug.ktr.entries up in case we don't have enough history here. http://nitrology.com/ktrdump-spinlock.txt Jason ___ 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
el...@sentor.se wrote this message on Wed, Oct 08, 2014 at 13:30 +0200: > > I guess this is a bug report for FreeBSD 10.0. > > > > Sometimes I can't kill my snort process on FreeBSD 10.0. > It won't die, even with kill -9. > > I'm not talking about a zombie process. Snort is a process that should > die normally. > I've run snort on over 100 nodes since FreeBSD v6.x and I've never seen > this behavior until now in FreeBSD 10.0. > > > Example: > > #ps faxuw > USER PID %CPU %MEMVSZRSS TT STAT STARTEDTIME > COMMAND > root49222 53.4 2.2 492648 183012 - Rs 11:46AM 7:05.59 > /usr/local/bin/snort -q -D -c snort.conf > root47937 0.0 2.2 488552 182864 - Ts 10:56AM29:35.98 > /usr/local/bin/snort -q -D -c snort.conf What is the MWCHAN? add l to the ps command... > The pid 47937 has been killed (repeatedly) with -9. > Its status is "Ts" meaning it is Stopped. have you tried to kill -CONT to resume it? > But it won't actually die and disappear. The only way to get rid of it > seem to be to reboot the machine. :-( > > (pid 49222 is the new process that was started after 47937 was killed) > > > The problem doesn't happen all the time and I haven't found any patterns > as to when it does. :-( > If I restart snort once every day, it fails to die approximately 2-4 times > per month. > Even though the problem doesn't happen on every kill, it is a definately a > recurring event. Can you run kgdb on the machine? (yes, it works on a live machine), use info threads to find the thread id, and then use thread to switch to it, and run bt to get a back trace... > I began to see it on a heavily loaded 10GE sensor, so I thought it could > have something to do with the ix driver, or the heavy load. > But now another FreeBSD 10.0-sensor had the exact same problem, and this > sensor don't have any 10GE NICs. In fact, this sensor has been running > just fine with both FreeBSD 9.1 and 9.3 for the past years. Snort has > always terminated correctly! After I reinstalled this machine with FreeBSD > 10.0 last friday, snort has then terminated correctly every day until > today, when it failed with the above pid 47937. (this sensor use the 'em' > driver, not 'ixgbe') > > I'm running snort with the same configuration, settings, version, daq, > libs, etc on 10.0 as I do on 9.3. > None of the 9.3 sensors have this problem, so it has to be something new > in FreeBSD 10.0. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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"
TCP receive window management
I have a question regarding the freeBSD receive window advertisement and
updating sender side flow control state based on this.
Is it expected that a retransmitted packet not carry an updated receive window?
The following are the state variables used for maintaining a peer's rcv window
state on the sender side. snd_wnd, snd_wl1, snd_wl2. In tcp_input at the label
step6: where these states are updated there are checks which make sure rcv
window is not updated by old segments.
if ((thflags & TH_ACK) &&
(SEQ_LT(tp->snd_wl1, th->th_seq) ||
(tp->snd_wl1 == th->th_seq && (SEQ_LT(tp->snd_wl2, th->th_ack) ||
(tp->snd_wl2 == th->th_ack && tiwin > tp->snd_wnd) {
Based on the above checks for the case of a fast retransmitted packet that does
ack additional data ((SEQ_LT(tp->snd_wl2, th->th_ack) is TRUE) and has the
latest rcv window. th_seq could be < snd_wl1 and in this case rcv window is not
updated to the latest one. Is this intentional or is there something that I am
missing.
Thanks
Madhu
___
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"
