Re: Silly experiments with netisr

> On Feb 5, 2015, at 12:03 PM, Sean Bruno wrote: > > > Signed PGP part > Some questions came up around the office and we ended up doing some > quite silly things with lo0 and netcat. > > If one runs a continuous netcat on localhost to another netcat listener > on localhost that writes the outp

Re: [rfc] migrate lagg to an rmlock

On Aug 29, 2013, at 7:42 AM, John Baldwin wrote: > On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote: >> There are a number of other places in the kernel where migration to an >> rmlock >> makes sense -- however, some care must be taken for four reasons: (1) while >> read locks don

Re: Flow ID, LACP, and igb

On Aug 26, 2013, at 5:30 PM, Adrian Chadd wrote: > ... is there any reason we wouldn't want to have the TX and RX for a given > flow mapped to the same core? > Given than an inbound ACK is likely to be turned into an outbound segment from within the same execution context and CPU instance, I c

Re: [rfc] migrate lagg to an rmlock

On Aug 24, 2013, at 12:14 PM, Alfred Perlstein wrote: > On 8/24/13 10:47 AM, Robert N. M. Watson wrote: >> On 24 Aug 2013, at 17:36, Alfred Perlstein wrote: >> We should distinguish "lock contention" from "line contention". When acquiring a rwlock on multiple CPUs concurrently, the c

Re: [net] protecting interfaces from races between control and data ?

Yup, it's an incredibly unsafe pattern. It also leads to the pattern where auxiliary processing is handed off to a taskqueue, which then interleaves the lock ownership with the ithread and produces out-of-order packet reception. Scott On Aug 8, 2013, at 5:18 PM, Adrian Chadd wrote: > .. and it

Re: [net] protecting interfaces from races between control and data ?

On Aug 7, 2013, at 10:16 PM, Warner Losh wrote: > > On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote: > >> .. and I bet it's not a design pattern, and this is total conjecture on my >> part: >> >> * the original drivers weren't SMP safe; >> * noone really sat down and figured out how to corre

Re: [net] protecting interfaces from races between control and data ?

On Aug 7, 2013, at 2:00 PM, Andre Oppermann wrote: > On 07.08.2013 09:18, Luigi Rizzo wrote: >> On Wed, Aug 7, 2013 at 5:26 AM, Mike Karels > > wrote: >>Jumping to (near) the end of the thread, I like most of Andre's proposal. >>Running with minimal locks at this

Re: [net] protecting interfaces from races between control and data ?

On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote: > .. and I bet it's not a design pattern, and this is total conjecture on my > part: > > * the original drivers weren't SMP safe; > * noone really sat down and figured out how to correctly synchronise > all of this stuff; > * people did the mini

Re: [net] protecting interfaces from races between control and data ?

On Aug 5, 2013, at 2:23 AM, Luigi Rizzo wrote: > i am slightly unclear of what mechanisms we use to prevent races > between interface being reconfigured (up/down/multicast setting, etc, > all causing reinitialization of the rx and tx rings) and > > i) packets from the host stack being sent out;

Re: Recommendations for 10gbps NIC

On Jul 28, 2013, at 2:42 PM, Jack Vogel wrote: > On Sat, Jul 27, 2013 at 9:22 AM, Andre Oppermann wrote: > >> On 27.07.2013 10:42, Alexander V. Chernikov wrote: >> >>> On 27.07.2013 12:15, Luigi Rizzo wrote: >>> On Sat, Jul 27, 2013 at 10:02 AM, Alexander V. Chernikov wrote:

Re: Recommendations for 10gbps NIC

We use both the chelsio and intel offerings Scott On Jul 25, 2013, at 2:10 PM, "Alexander V. Chernikov" wrote: > On 25.07.2013 00:26, Boris Kochergin wrote: >> Hi. > Hello. >> >> I am looking for recommendations for a 10gbps NIC from someone who has >> successfully used it on FreeBSD. It will

Re: LACP LAGG device problems

Adrian, you're killing my spam filter! But yes, our use of FreeBSD at Netflix is hardly a science project. Http://openconnect.netflix.com Scott On Jul 21, 2013, at 1:31 PM, Adrian Chadd wrote: > Barney, > > I now work at netflix. We push >10gig per box. I'm working on making > that much, mu

Re: Terrible ix performance

On Jul 2, 2013, at 10:28 PM, Outback Dingo wrote: > Ive got a high end storage server here, iperf shows decent network io > > > the card has a 3 meter twinax cable from cisco connected to it, going > through a fujitsu switch. We have tweaked various networking, and kernel > sysctls, however fr

Re: Looking for a bgp listener that works with RADIX_MPATH / EQMP that's in HEAD

We run bird for this task. Can't say if it works on 10 since he haven't moved to 10 yet, but there have been some experiments with running a 10 kernel in the 9 userland and bird seems to behave fine with that. Scott On Jun 29, 2013, at 1:50 PM, Peter Wemm wrote: > I'm looking for pointers to s

Re: High CPU interrupt load on intel I350T4 with igb on 8.3

On May 11, 2013, at 2:12 PM, Hooman Fazaeli wrote: > On 5/11/2013 8:26 PM, Barney Cordoba wrote: >> Clearly you don't understand the problem. Your logic is that because other >> drivers are defective also; therefore its not a driver problem? The problem >> is caused by a multi-threaded driver

Re: ipfilter(4) needs maintainer

On Apr 15, 2013, at 1:27 PM, Cy Schubert wrote: > In message , Scott Long > writes: >> >> On Apr 15, 2013, at 11:48 AM, Cy Schubert wrote: >> >>> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo >>> writes: >>

Re: ipfilter(4) needs maintainer

On Apr 15, 2013, at 11:48 AM, Cy Schubert wrote: > In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo > writes: >> 2013/04/15 9:55$B!"(BCy Schubert >> $B$N%a%C%;!<%8(B: >> >>> I've been planning on taking on IP Filter for quite some time. >>> Unfortunately I've left

Re: ipfilter(4) needs maintainer

The desire to remove it stems from the inability to give it adequate engineering service as the network stack evolves. Simply taking it out of a kernel config file doesn't address that problem at all. If it's going to stay in FreeBSD at all, it needs to be maintained. This could be set about

Re: ipfilter(4) needs maintainer

On Apr 14, 2013, at 7:20 AM, Joe wrote: > Rui Paulo wrote: >> On 2013/04/12, at 22:31, Scott Long wrote: >>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: >>> >>>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote: >>>> >>>>&g

Re: ipfilter(4) needs maintainer

On Apr 13, 2013, at 11:43 AM, Rui Paulo wrote: > On 2013/04/13, at 5:03, Scott Long wrote: >> You target audience for this isn't people who track CURRENT, it's people who >> are on 7, 8, or 9 and looking to update to 10.x sometime in the future. > > Yes, I&#

Re: ipfilter(4) needs maintainer

On Apr 13, 2013, at 12:33 AM, Rui Paulo wrote: > On 2013/04/12, at 22:31, Scott Long wrote: > >> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: >> >>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote: >>> >>>> Lack of maintainer in a near fu

Re: ipfilter(4) needs maintainer

On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: > On 2013/04/11, at 13:18, Gleb Smirnoff wrote: > >> Lack of maintainer in a near future would lead to bitrot due to changes >> in other areas of network stack, kernel APIs, etc. This already happens, >> many changes during 10.0-CURRENT cycle were

Re: igb and ALTQ in 9.1-rc3

Comedy gold. It's been a while since I've seen this much idiocy from you, Barney. Hopefully the rest of the mailing list will blackhole you, as I'm about to, and we can all get back to real work. Scott On Mar 29, 2013, at 10:38 AM, Barney Cordoba wrote: > it needs a lot more than a patch.

Re: Problems with two interfaces on the same subnet?

On Feb 12, 2013, at 11:06 AM, Ivan Voras wrote: > On 12/02/2013 18:57, Ivan Voras wrote: >> On 12/02/2013 18:52, Freddie Cash wrote: >>> Any reason you can't just use lagg(4) in one of the non-LACP modes? That's >>> bascially designed to do exactly what you want. >> >> No particular reason, I'

Re: potential nasty bug in igb and ixgbe

I'll bite. Scott On Wed, 1 Oct 2008, Jack Vogel wrote: Jeff Roberson uncovered an issue that might be behind any number of possible problems. Our newer hardware (meaning those supported by the igb and ixgbe drivers) overwrites the buffer address in the RX descriptor with a variety of data in

Re: MFC of em/igb drivers

Jack Vogel wrote: On Sat, May 3, 2008 at 4:45 AM, Kostik Belousov <[EMAIL PROTECTED]> wrote: On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: I got the new drivers in Friday afternoon for those that don't see CVS > messages. > > The igb driver is for 82575 and 82576 adapters, i

Re: Packet loss every 30.999 seconds

Bruce Evans wrote: On Mon, 17 Dec 2007, David G Lawrence wrote: One more comment on my last email... The patch that I included is not meant as a real fix - it is just a bandaid. The real problem appears to be that a very large number of vnodes (all of them?) are getting synced (i.e. calling f

Re: Proposed #ifdef change to em

Jack Vogel wrote: I have found that the FAST interrupt handling is implicated in the watchdog resets that I have seen. What I plan to do is revert to the way 6.2 had things, meaning that FAST interrupts will be available but defined off by default. I wanted to know if anyone has an issue with

Re: RFC: Evolution of the em driver

Jack Vogel wrote: On 10/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: At Mon, 29 Oct 2007 10:45:17 -0700, Jack Vogel wrote: I have an important decision to make and I thought rather than just make it and spring it on you I'd present the issues and see what opinions were. Our newer hardwa

Re: Request for feedback on common data backstore in the kernel

Hans Petter Selasky wrote: Hi Scott, The discussion has been moved to "[EMAIL PROTECTED]". Please only reply there next time. On Wednesday 26 September 2007, Scott Long wrote: Hans Petter Selasky wrote: Hi, Please keep me CC'ed, hence I'm not on all these list

Re: Request for feedback on common data backstore in the kernel

Hans Petter Selasky wrote: Hi, Please keep me CC'ed, hence I'm not on all these lists. In the kernel we currently have two different data backstores: struct mbuf and struct buf These two backstores serve two different device types. "mbufs" are for network devices and "buf" is for disk de

Re: Thoughts on vlan filter

Jack Vogel wrote: I had an idea, I was debugging a problem on my new 10G driver a week back, and found I had the hardware vlan filter enabled by accident, this led me to wonder about supporting this hardware feature in the driver... I have done some experimentation, and find that when the vlan d

Re: Proposed 6.2 em RELEASE patch

Mike Tancsa wrote: At 12:50 PM 11/13/2006, Ivan Voras wrote: Mike Tancsa wrote: > At 12:15 AM 11/13/2006, Scott Long wrote: > >> Is this with EM_INTR_FAST enabled also? > > Yes. Havent done the stock case yet, but will do so later today. Do you have a comparison with Li

Re: Proposed 6.2 em RELEASE patch

Mike Tancsa wrote: At 12:15 AM 11/13/2006, Scott Long wrote: Is this with EM_INTR_FAST enabled also? Without it, the 2 streams are definitely lossy on the management interface ---Mike Ok, and would you be able to test the polling options as well? Scott

Re: Proposed 6.2 em RELEASE patch

Mike Tancsa wrote: At 11:05 PM 11/12/2006, Scott Long wrote: Mike Tancsa wrote: However, if I turn on fastforwarding, its back to the old behavior with it locking up. This was with the stock driver. I will try the same test with #define EM_FAST_INTR 1 as well as taking out the nfs option

Re: Proposed 6.2 em RELEASE patch

Mike Tancsa wrote: However, if I turn on fastforwarding, its back to the old behavior with it locking up. This was with the stock driver. I will try the same test with #define EM_FAST_INTR 1 as well as taking out the nfs option from the kernel driver. Anything else to tune with ?

Re: Proposed 6.2 em RELEASE patch

Mike Tancsa wrote: At 11:41 AM 11/12/2006, Scott Long wrote: Mike Tancsa wrote: At 01:42 AM 11/11/2006, Scott Long wrote: driver. What will help me is if you can hook up a serial console to your machine and see if it can be made to drop to the debugger while it is under load and otherwise

Re: Proposed 6.2 em RELEASE patch

Mike Tancsa wrote: At 01:42 AM 11/11/2006, Scott Long wrote: driver. What will help me is if you can hook up a serial console to your machine and see if it can be made to drop to the debugger while it is under load and otherwise unresponsive. If you can, getting a process dump might help

Re: Proposed 6.2 em RELEASE patch

Mike Tancsa wrote: At 05:00 PM 11/10/2006, Jack Vogel wrote: On 11/10/06, Mike Tancsa <[EMAIL PROTECTED]> wrote: Some more tests. I tried again with what was committed to today's RELENG_6. I am guessing its pretty well the same patch. Polling is the only way to avoid livelock at a high pps ra

Re: Proposed 6.2 em RELEASE patch

Mike Tancsa wrote: At 08:19 PM 11/8/2006, Jack Vogel wrote: BUT, I've added the FAST_INTR changes back into the code, so if you go into your Makefile and add -DEM_FAST_INTR you will then get the taskqueue stuff. It certainly does make a difference performance wise. I did some quick testing

Re: new em-driver still broken

Mikhail Teterin wrote: On Saturday 21 October 2006 13:33, Gleb Smirnoff wrote: = We aren't currently speaking about performance, we need to know whether = kernel with DEVICE_POLLING option makes NIC work stable. Having noticed today's em-driver update, I rebuilt world/kernel and tried the dump-t

Re: em network issues

Jack Vogel wrote: On 10/25/06, Scott Long <[EMAIL PROTECTED]> wrote: Jack Vogel wrote: > On 10/25/06, Doug Ambrisko <[EMAIL PROTECTED]> wrote: > >> 3) In em_process_receive_interrupts/em_rxeof always decrement >> the count on every run th

Re: em network issues

Jack Vogel wrote: On 10/25/06, Doug Ambrisko <[EMAIL PROTECTED]> wrote: 3) In em_process_receive_interrupts/em_rxeof always decrement the count on every run through the loop. If you notice count is an is an int that starts at the passed in value of -1. It then cou

Re: em network issues

Doug Ambrisko wrote: John Polstra writes: | On 19-Oct-2006 Scott Long wrote: | > The performance measurements that Andre and I did early this year showed | > that the INTR_FAST handler provided a very large benefit. | | I'm trying to understand why that's the case.

Re: em network issues

Bruce Evans wrote: On Thu, 19 Oct 2006, John Polstra wrote: On 19-Oct-2006 Scott Long wrote: The performance measurements that Andre and I did early this year showed that the INTR_FAST handler provided a very large benefit. I'm trying to understand why that's the case. Is it

Re: em network issues

John Polstra wrote: On 19-Oct-2006 Scott Long wrote: The performance measurements that Andre and I did early this year showed that the INTR_FAST handler provided a very large benefit. I'm trying to understand why that's the case. Is it because an INTR_FAST interrupt doesn't ha

Re: em network issues

Bruce Evans wrote: On Thu, 19 Oct 2006, Scott Long wrote: Bruce Evans wrote: On Wed, 18 Oct 2006, Kris Kennaway wrote: I have been working with someone's system that has em shared with fxp, and a simple fetch over the em (e.g. of a 10 GB file of zeroes) is enough to produce wat

Re: em network issues

Bruce Evans wrote: On Wed, 18 Oct 2006, Scott Long wrote: [too much quoted; much deleted] Bruce Evans wrote: On Wed, 18 Oct 2006, Kris Kennaway wrote: I have been working with someone's system that has em shared with fxp, and a simple fetch over the em (e.g. of a 10 GB file of zeroe

Re: em network issues

Bruce Evans wrote: On Wed, 18 Oct 2006, Kris Kennaway wrote: I have been working with someone's system that has em shared with fxp, and a simple fetch over the em (e.g. of a 10 GB file of zeroes) is enough to produce watchdog timeouts after a few seconds. As previously mentioned, changing the

Re: em interrupt storm

Michael Vince wrote: Scott Long wrote: Michael Vince wrote: Kris Kennaway wrote: On Tue, Nov 22, 2005 at 08:54:49PM -0800, John Polstra wrote: On 23-Nov-2005 Kris Kennaway wrote: I am seeing the em driver undergoing an interrupt storm whenever the amr driver receives interrupts

Re: em interrupt storm

Mihail Balikov wrote: try to enable kern.polling sysctl -w kern.polling.enable=1 Polling solves specific problems, but isn't a good choice for every situation. Scott ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listin

Re: em interrupt storm

Michael Vince wrote: Kris Kennaway wrote: On Tue, Nov 22, 2005 at 08:54:49PM -0800, John Polstra wrote: On 23-Nov-2005 Kris Kennaway wrote: I am seeing the em driver undergoing an interrupt storm whenever the amr driver receives interrupts. In this case I was running newfs on the amr

Re: FreeBSD Memory Management questions ?

John-Mark Gurney wrote: Aziz Kezzou wrote this message on Tue, Jun 14, 2005 at 04:21 -0400: I have two questions concerning FreeBSD Memory management : 1 - Right now to access the memory address space of a user process from kernel mode, I only have to set, on x86 systems, the register CR3 to

Re: iSCSI initiator driver beta version, testers wanted

Danny Braniss wrote: Scott Long wrote: Danny Braniss wrote: with tags enabled, iSCSI is much faster, but it also causes a deadlock :-( this is what i run: newfs -U / cd / restore rf /home/file.dump on the same motherboard, a dual Xeon, with smp disabled all is OK with smp enabled

Re: iSCSI initiator driver beta version, testers wanted

Scott Long wrote: Danny Braniss wrote: with tags enabled, iSCSI is much faster, but it also causes a deadlock :-( this is what i run: newfs -U / cd / restore rf /home/file.dump on the same motherboard, a dual Xeon, with smp disabled all is OK with smp enabled restore gets stuck

Re: iSCSI initiator driver beta version, testers wanted

Danny Braniss wrote: with tags enabled, iSCSI is much faster, but it also causes a deadlock :-( this is what i run: newfs -U / cd / restore rf /home/file.dump on the same motherboard, a dual Xeon, with smp disabled all is OK with smp enabled restore gets stuck usualy waiting

Re: netgraph only on i386/ia64 - why ?

Ruslan Ermilov wrote: On Wed, Aug 18, 2004 at 01:56:14PM -0700, Julian Elischer wrote: [...] re: I'll do the commit to -current today.. what other files should I change..? UPDATING (user utilitiesw will need recompile) UPDATING for sure, followed by a HEADS UP message to [EMAIL PROTECTED] and I gu

Re: netgraph only on i386/ia64 - why ?

John Polstra wrote: On 18-Aug-2004 Julian Elischer wrote: John Polstra wrote: There is one problem with netgraph on 64-bit platforms. The ng_msghdr struct is 52 bytes / 4-byte aligned (see ng_message.h). That means the message payload is not well-aligned for 64-bit platforms. It would be nice to

Re: em(4) problems.

John Baldwin wrote: On Thursday 06 May 2004 04:47 pm, Scott Long wrote: Søren Schmidt wrote: Petri Helenius wrote: I´m highly confident that this is a case of integrated "CSA" ethernet with broken BIOS. I suspect you get an message about that when booting. Nope. no messages to that

Re: em(4) problems.

Søren Schmidt wrote: Petri Helenius wrote: I´m highly confident that this is a case of integrated "CSA" ethernet with broken BIOS. I suspect you get an message about that when booting. Nope. no messages to that effect, oh and it works in windows(tm)... The last thing I see if I try to use em0 is:

Re: em(4) problems.

Søren Schmidt wrote: Petri Helenius wrote: I´m highly confident that this is a case of integrated "CSA" ethernet with broken BIOS. I suspect you get an message about that when booting. Nope. no messages to that effect, oh and it works in windows(tm)... The last thing I see if I try to use em0 is: