RE: kern/161899: Repeating RTM_MISS packets causing high CPU load for ntpd
Hmm... I don't see this problem until multiple FIBs are enabled. --Qing > -Original Message- > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- > n...@freebsd.org] On Behalf Of Steven Hartland > Sent: Wednesday, February 08, 2012 11:13 AM > To: Gary Palmer > Cc: freebsd-net@freebsd.org; Gleb Smirnoff > Subject: Re: kern/161899: Repeating RTM_MISS packets causing high CPU > load for ntpd > > - Original Message - > From: "Gary Palmer" > >> Running the following commands does indeed stop this > >> route add -inet6 :::0.0.0.0 -prefixlen 96 ::1 -reject > >> route add -inet6 ::0.0.0.0 -prefixlen 96 ::1 -reject > >> > >> I found these in /etc/rc.d/network_ipv6 but I can't see why > >> these wouldnt be run on a machine that doesn't have an IPv6 > >> address, they seem to be added correctly on machines that do. > > > > Speculation: the machine(s) which didn't have the routes maybe > > didn't have > > > > ipv6_enable="YES" > > > > in /etc/rc.conf? > > Doh! > > Indeed they don't so of course /etc/rc.d/network_ipv6 doesnt > start but IPv6 is in the kernel and ipv6 is configured on lo0 via > /etc/rc.d/auto_linklocal so it looks like ipv6 is enabled even > though it isnt. > > Given this would a reasonable patch be to move the internal routing > to auto_linklocal i.e. these lines:- > # disallow "internal" addresses to appear on the wire > route add -inet6 :::0.0.0.0 -prefixlen 96 ::1 -reject > route add -inet6 ::0.0.0.0 -prefixlen 96 ::1 -reject > > Seems the relavent fix was part of a much bigger commit:- > http://svnweb.freebsd.org/base?view=revision&revision=197139 > > So it may not be easy to patch this into 8.x > > Regards > Steve > > > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, printing > or otherwise disseminating it or any information contained in it. > > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmas...@multiplay.co.uk. > > ___ > 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: Missed packet on recent em(4)
Hi, On Wed, Feb 8, 2012 at 7:15 PM, Vogel, Jack wrote: > The NETMAP code is all self-contained, just delete what's inside the ifdef's > not exactly, the allocator stuff from r229939 is not that self contained, but beside that my problem is more to get the patches to apply to our internal 7-STABLE tree. My generic workflow is to mindlessly use git-format-patch to generate the set of patches, slightly reformat commit log to our internal standard, and apply that on top of the target tree. I then let git figures out eventual conflicts and fix them. I do not want to have to think about all the things we changed internally which might conflict, but also want to keep record of who made what change in which commit/revision. To some extend, I want to avoid the mess which happened in `sys/dev/e1000/' where you blew luigi@ and other committers changes by blindly committing stuff and letting them fix the damage afterward. These few commits were just wonderful, I must admit you made my day a little less sad ;-) - Arnaud > Jack > > > -Original Message- > From: Arnaud Lacombe [mailto:lacom...@gmail.com] > Sent: Wednesday, February 08, 2012 3:25 PM > To: Vogel, Jack > Cc: freebsd-net@freebsd.org > Subject: Missed packet on recent em(4) > > Hi Jack, > > For the record, on the following hardware: > > em3@pci0:5:0:0: class=0x02 card=0x150415bb chip=0x150c8086 rev=0x00 > hdr=0x00 > > and the following version of em(4): > > em3: port 0xec00-0xec1f > mem 0xfebe-0xfebf,0xfebdc000-0xfebd irq 19 at device 0.0 > on pci5 > em3: Using an MSI interrupt > em3: [FILTER] > em3: Ethernet address: 00:90:fb:35:18:b1 > > backported to 7-STABLE, I am still getting `missed_packets' increment, > without any obvious mbuf allocation denial. These increments do not > translate into complete hang of the driver, just crazy frame loss. > > # sysctl dev.em.3 > dev.em.3.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 > dev.em.3.%driver: em > dev.em.3.%location: slot=0 function=0 > dev.em.3.%pnpinfo: vendor=0x8086 device=0x150c subvendor=0x15bb > subdevice=0x1504 class=0x02 > dev.em.3.%parent: pci5 > dev.em.3.rx_int_delay: 0 > dev.em.3.tx_int_delay: 66 > dev.em.3.rx_abs_int_delay: 66 > dev.em.3.tx_abs_int_delay: 66 > dev.em.3.rx_processing_limit: 100 > dev.em.3.flow_control: 3 > dev.em.3.eee_control: 0 > dev.em.3.link_irq: 0 > dev.em.3.mbuf_alloc_fail: 0 > dev.em.3.cluster_alloc_fail: 0 > dev.em.3.dropped: 0 > dev.em.3.tx_dma_fail: 0 > dev.em.3.rx_overruns: 78 > dev.em.3.watchdog_timeouts: 0 > dev.em.3.device_control: 1477444168 > dev.em.3.rx_control: 67141634 > dev.em.3.fc_high_water: 18432 > dev.em.3.fc_low_water: 16932 > dev.em.3.queue0.txd_head: 703 > dev.em.3.queue0.txd_tail: 703 > dev.em.3.queue0.tx_irq: 0 > dev.em.3.queue0.no_desc_avail: 0 > dev.em.3.queue0.rxd_head: 692 > dev.em.3.queue0.rxd_tail: 691 > dev.em.3.queue0.rx_irq: 0 > dev.em.3.mac_stats.excess_coll: 0 > dev.em.3.mac_stats.single_coll: 0 > dev.em.3.mac_stats.multiple_coll: 0 > dev.em.3.mac_stats.late_coll: 0 > dev.em.3.mac_stats.collision_count: 0 > dev.em.3.mac_stats.symbol_errors: 0 > dev.em.3.mac_stats.sequence_errors: 0 > dev.em.3.mac_stats.defer_count: 0 > dev.em.3.mac_stats.missed_packets: 1135790 > dev.em.3.mac_stats.recv_no_buff: 555763 > dev.em.3.mac_stats.recv_undersize: 0 > dev.em.3.mac_stats.recv_fragmented: 0 > dev.em.3.mac_stats.recv_oversize: 0 > dev.em.3.mac_stats.recv_jabber: 0 > dev.em.3.mac_stats.recv_errs: 0 > dev.em.3.mac_stats.crc_errs: 0 > dev.em.3.mac_stats.alignment_errs: 0 > dev.em.3.mac_stats.coll_ext_errs: 0 > dev.em.3.mac_stats.xon_recvd: 6806 > dev.em.3.mac_stats.xon_txd: 253 > dev.em.3.mac_stats.xoff_recvd: 7583 > dev.em.3.mac_stats.xoff_txd: 742908 > dev.em.3.mac_stats.total_pkts_recvd: 3904354 > dev.em.3.mac_stats.good_pkts_recvd: 2761900 > [...] > > This happened with about 1000 short-lived TCP connection filling about > 100Mbps of traffic. > > I saw you made updates to the driver recently. I'll attempt a backport > and let you know. This might not be trivial given the netmap mess > which appeared in -current... > > - Arnaud ___ 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: [PATCH] multiple instances of ipfw(4)
On 2/8/12 6:09 AM, Gleb Smirnoff wrote: On Wed, Feb 08, 2012 at 03:04:09PM +0100, Ermal Lu?i wrote: E> 2012/2/8 Gleb Smirnoff: E> > On Tue, Jan 31, 2012 at 12:02:04PM +0100, Luigi Rizzo wrote: E> > L> if i understand what the patch does, i think it makes sense to be E> > L> able to hook ipfw instances to specific interfaces/sets of interfaces, E> > L> as it permits the writing of more readable rulesets. Right now the E> > L> workaround is start the ruleset with skipto rules matching on E> > L> interface names, and then use some discipline in "reserving" a range E> > L> of rule numbers to each interface. E> > E> > This is definitely a desired feature, but it should be implemented E> > on level of pfil(9). However, that would still require multiple E> > instances of ipfw(4). E> > E> This opens a discussion of architecture design. E> I do not think presently pfil(9) is designed to handle such thing! Several years ago, I guess around 2005, a discussion on a per-interface packet filtering was taken on the net@ mailing list. In that time, it lead to nothing, several people were against the idea. Recently on IRC I had raised the discussion again. Today more people liked the idea and found it a desired feature. Many kinds of high end networking equipment have per-interface ACLs. I know that networking sysadmins would be happy if FreeBSD packet filters would get this feature, since maintaing such ACLs is much easier on a router with dozens of interfaces. I think it is a good idea. not only for interfaces but certain routing and bridging paths too. ___ 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/161899: Repeating RTM_MISS packets causing high CPU load for ntpd
- Original Message - From: "Li, Qing" Hmm... I don't see this problem until multiple FIBs are enabled. I have a bog standard box here one default route and one active nic, which exhibits this issue so there shouldn't be multiple FIB's unless the fact that IPv6 is compiled in and active on lo0 making this so? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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"
