Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE
Dear Jason With a link_irq of 4, I still guess your problem is snd_buf filling up during a temporary link_loss (see: http://lists.freebsd.org/pipermail/freebsd-net/2011-November/030424.html). I use a patched version of e1000 which addresses this issue and works good for me but it is based on 7.2.3 and I have just tested in on 7.3-RELEASE. If interested, I can send you the sources for test. You may also port my changes to 7.3.2 and roll your own version. On 3/8/2012 12:27 AM, Jason Wolfe wrote: I'm sure it's getting old with all of the recent work put into the e1000 driver, but this is still ongoing with MSI-X enabled. Most machines are running an 8.2-STABLE from early Feb, though it appears there have been no relevant changes in RELENG_8 since then. I've disabled all possible em options on the devices also to rule that out and am still seeing the issue. I guess reverting back to MSI-X disabled is the next step if nothing is spotted. This box had been doing between 1 and 1.5Gb/s steady for the 26 days before the network hang. ___ 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 9.0 some tuning for Best performance for 85598 intel controller
Hello, I try to build server for = syn flood rezist.. i buy IBM x3650 with 24 core xeon cpu, 64 gbit Ram, = SSD disk.. Also i plug in 52598 intel Intel® 10 Gigabit XF SR Server = Adapter CARD on it. I install FreeBSD 9.0 Release version. And i find = ixbge-2.4.4.tar.gz driver and i install on = FreeBSD I checked document = and support pages for = intel.. i didnt find any improve = performance document for FreeBSD.. Like this [1]http://www.intel.com/content/www/us/en/ethernet-control lers/82575-82576-82598-82599-ethernet-controllers-latency-appl-note.ht ml<= /a> (this is good for linux) But i dont see any freebsd = documentation.. I need to improve more better for performance.. = Can you help me about this case ? .. Because i know this network card = can handle more pps.. (i noticed 600.000 pps without input error with = this configuration with 46 byte syn packets my best performance at thismoment on open port). but i want to build for 2.000.000 pps syn flood = rezisting ... I see only 8 irq rx queues = for handling.. but i got 24 core cpu.. how can assign more cpu for = better performance. (i attached screen for 8 queue) ( how can i assign = more then 8 core.. ) Also Finally = i need tuning for ixgbe-2.4.4 driver or change freebsd kernel params for = better performance ? Can anybody = knows about that dev.ix.0.dropped: = 0 dev.ix.0.mbuf_defrag_failed: = 0 dev.ix.0.no_tx_dma_setup: = 0 dev.ix.0.watchdog_events: = 0 dev.ix.0.tso_tx: 0 dev.ix.0.link_irq: = 0 dev.ix.0.queue0.interrupt_rate: = 0 dev.ix.0.queue0.txd_head: = 0 dev.ix.0.queue0.txd_tail: = 0 dev.ix.0.queue0.no_desc_avail: = 0 dev.ix.0.queue0.tx_packets: = 0 dev.ix.0.queue0.rxd_head: = 0 dev.ix.0.queue0.rxd_tail: = 0 dev.ix.0.queue0.rx_packets: = 0 dev.ix.0.queue0.rx_bytes: = 0 dev.ix.0.queue0.lro_queued: = 0 dev.ix.0.queue0.lro_flushed: = 0 dev.ix.0.queue1.interrupt_rate: = 0 dev.ix.0.queue1.txd_head: = 0 dev.ix.0.queue1.txd_tail: = 0 dev.ix.0.queue1.no_desc_avail: = 0 dev.ix.0.queue1.tx_packets: = 0 dev.ix.0.queue1.rxd_head: = 0 dev.ix.0.queue1.rxd_tail: = 0 dev.ix.0.queue1.rx_packets: = 0 dev.ix.0.queue1.rx_bytes: = 0 dev.ix.0.queue1.lro_queued: = 0 dev.ix.0.queue1.lro_flushed: = 0 dev.ix.0.queue2.interrupt_rate: = 0 dev.ix.0.queue2.txd_head: = 0 dev.ix.0.queue2.txd_tail: = 0 dev.ix.0.queue2.no_desc_avail: = 0 dev.ix.0.queue2.tx_packets: = 0 dev.ix.0.queue2.rxd_head: = 0 dev.ix.0.queue2.rxd_tail: = 0 dev.ix.0.queue2.rx_packets: = 0 dev.ix.0.queue2.rx_bytes: = 0 dev.ix.0.queue2.lro_queued: = 0 dev.ix.0.queue2.lro_flushed: = 0 dev.ix.0.queue3.interrupt_rate: = 0 dev.ix.0.queue3.txd_head: = 0 dev.ix.0.queue3.txd_tail: = 0 dev.ix.0.queue3.no_desc_avail: = 0 dev.ix.0.queue3.tx_packets: = 0 dev.ix.0.queue3.rxd_head: = 0 dev.ix.0.queue3.rxd_tail: = 0 dev.ix.0.queue3.rx_packets: = 0 dev.ix.0.queue3.rx_bytes: = 0 dev.ix.0.queue3.lro_queued: = 0 dev.ix.0.queue3.lro_flushed: = 0 dev.ix.0.queue4.interrupt_rate: = 0 dev.ix.0.queue4.txd_head: = 0 dev.ix.0.queue4.txd_tail: = 0 dev.ix.0.queue4.no_desc_avail: = 0 dev.ix.0.queue4.tx_packets: = 0 dev.ix.0.queue4.rxd_head: = 0 dev.ix.0.queue4.rxd_tail: = 0 dev.ix.0.queue4.rx_packets: = 0 dev.ix.0.queue4.rx_bytes: = 0 dev.ix.0.queue4.lro_queued: = 0 dev.ix.0.queue4.lro_flushed: = 0 dev.ix.0.queue5.interrupt_rate: = 0 dev.ix.0.queue5.txd_head: = 0 dev.ix.0.queue5.txd_tail: = 0 dev.ix.0.queue5.no_desc_avail: = 0 dev.ix.0.queue5.tx_packets: = 0 dev.ix.0.queue5.rxd_head: = 0 dev.ix.0.queue5.rxd_tail: = 0 dev.ix.0.queue5.rx_packets: = 0 dev.ix.0.queue5.rx_bytes: = 0 dev.ix.0.queue5.lro_queued: = 0 dev.ix.0.queue5.lro_flushed: = 0 dev.ix.0.queue6.interrupt_rate: = 0 dev.ix.0.queue6.txd_head: = 0 dev.ix.0.queue6.txd_tail: = 0 dev.ix.0.queue6.no_desc_avail: = 0 dev.ix.0.queue6.tx_packets: = 0 dev.ix.0.queue6.rxd_head: = 0 dev.ix.0.queue6.rxd_tail: = 0 dev.ix.0.queue6.rx_packets: = 0 dev.ix.0.queue6.rx_bytes: = 0 dev.ix.0.queue6.lro_queued: = 0 dev.ix.0.queue6.lro_flushed: = 0 dev.ix.0.queue7.interrupt_rate: = 0 dev.ix.0.queue7.txd_head: = 0 dev.ix.0.queue7.txd_tail: = 0 dev.ix.0.queue7.no_desc_avail: = 0 dev.ix.0.queue7.tx_packets: = 0 dev.ix.0.queue7.rxd_head: = 0 dev.ix.0.queue7.rxd_tail: = 0 dev.ix.0.queue7.rx_packets: = 0 dev.ix.0.queue7.rx_bytes: = 0 dev.ix.0.queue7.lro_queued: = 0 dev.ix.0.queue7.lro_flushed: = 0 Here my driver, bsd# dmesg | grep = ix module_register: module pci/ixgbe already = exists! Module pci/ixgbe failed to register: = 17 module_register: module pci/ixv already = exists! Module pci/ixv failed to register: = 17 a
Re: Strong host model in IPv6?
At Fri, 9 Mar 2012 23:26:01 +, Alex Yong wrote: > I've spotted that in IPv4 there is the sysctl "net.inet.ip.check_interface" > which defaults to set, but I've been unable to find any guarantees that > strong host model is enforced in v6 in the comments or internet. According > to the IPv6 Core Protocols Implementation book (3.7 "Input processing: > ip6_input() Function") the incoming network packet processing in ip6_input > should use the routing table to look up whether packets are of relevance > for an interface - but the code base has diverged significantly since then > including vnets for jails which makes me wonder if this is a bug. However I've not closely followed the most recent version of FreeBSD IPv6 code, but the use of the routing table in ip6_input in the original KAME implementation had nothing to do with the strong host model. It was just for faster determination of whether an incoming packet is destined to *any* of host's IPv6 addresses (on any interface, which may or may not be identical to the receiving interface). --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ 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: Strong host model in IPv6?
On 10 March 2012 18:27, JINMEI Tatuya / 神明達哉 wrote: > I've not closely followed the most recent version of FreeBSD IPv6 > code, but the use of the routing table in ip6_input in the original > KAME implementation had nothing to do with the strong host model. It > was just for faster determination of whether an incoming packet is > destined to *any* of host's IPv6 addresses (on any interface, which > may or may not be identical to the receiving interface). > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > Ah! That route lookup indeed doesn't ever actually compare the interface that route is configured for. For some reason I convinced myself rtalloc filters by interface - which is clearly wrong... Sorry for misquoting your text -- that's what I get for trying to be well prepared. My question still stands though, am I crazy in trying to have a strong model for v6 (does this for some reason not make sense?), does KAME already do this and I've just missed it, or (least likely) am I right in thinking it doesn't support it and this wouldn't be crazy? Many thanks for the help so far. AlexY ___ 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: Intel 82574L interface wedging - em7.3.2/8.2-STABLE
On 10 March 2012 02:33, Hooman Fazaeli wrote: > Dear Jason > > With a link_irq of 4, I still guess your problem is snd_buf filling up > during > a temporary link_loss (see: > http://lists.freebsd.org/pipermail/freebsd-net/2011-November/030424.html). > > I use a patched version of e1000 which addresses this issue and > works good for me but it is based on 7.2.3 and I have just tested in > on 7.3-RELEASE. Are you able to post the patch here? Maybe Jack can look at what's going on and apply it to the latest intel ethernet driver. Adrian ___ 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: problem with vlan interfaces tagging/untagging in a simulated switch box
let me explain my problem with this type of topology when I want to simulate a switch like cisco eth1 -+ --- bridge1 --- vlan9 --+-- eth0 --- trunk0 | eth2 -+ --- bridge2 --- vlan8 --+ On 3/6/12, Peter Jeremy wrote: > On 2012-Mar-06 09:15:57 +0330, h bagade wrote: >>On 3/6/12, Peter Jeremy wrote: >>> The following example diagram shows 3 distinct packet flows: >>> - packets tagged 5 in trunk1 and 6 in trunk0 >>> - packets tagged 7 in trunk1 and 9 in trunk0 >>> - packets tagged 8 in trunk0 and 10 in trunk2 >>> >>> +-- vlan5 --- bridge1 --- vlan6 --+ >>> | | >>> trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 >>>| >>>bridge3 --- vlan8 --+ >>> | >>> trunk2 -- eth2 --- vlan10 >>> >>I've described the function of Cisco switches in vlan >>tagging/untagging. > > Real switches typically have everything tagged internally, with the > native VLAN tags added/removed at the ingress/egress ports. This > simplifies the internal switch logic (at the expense of meaning that > tags have to be consistent across all trunks). > > FreeBSD works differently. Packets are _untagged_ internally and you > need a separate bridge(4) device for each broadcast domain (vlan). > >> In your topology, packets should be tagged when >>recieved on real interfaces to be send out to vlan interfaces. > > Packets are never tagged by real interfaces and always have tags > added/removed by vlan devices. > >> It >>would be fine when two trunks are communicating because on both side >>packets are tagged. But as I mentioned before, Cisco switches receive >>packets on an interface untagged and then sending packets tagged out >>of trunk port, based on which interface it receives, > > You can connect a physical interface (ethX) directly to a bridge device > to access untagged packets. Note that I'm not sure whether it is safe > to access the native VLAN in a trunk in this way. > > To continue the above example, > ifconfig bridge1 addm eth3 > would result in packets arriving on eth3 leaving tagged as vlan 5 in > trunk1, vlan 6 in trunk0 and vice versa. > > -- > Peter Jeremy > ___ 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: problem with vlan interfaces tagging/untagging in a simulated switch box
Sorry my last post was sent out suddenly by pressing a key, I don't yet know even which one! the compelete post is written down here. let me explain my problem with this type of topology when I want to simulate a switch like cisco eth0 -+ | eth1 -+ --- bridge1 --- vlan9 --+-- eth4 - outside of switch | | eth2 -+ --- bridge2 --- vlan8 --+ | | eth3 -+ bridge3 ---+ In above example, eth0 and eth1 are vlan9 ports which means that traffic coming from these ports are sent out eth4(trunk port) with vlan9 tag. the same for eth2 which is vlan8 port. eth3 is the port with vlan id equal to native vlan on eth4. the native vlans are those vlans which would not tag across trunk port, so traffic comes from eth3 pass the trunk port(eth4) untagged. the scenario works fine without eth3! it means that when eth3 is excluded from the topology, the other ports are tagged the proper vlan tag when going through eth4. As eth3 is added the all traffic receives on eth4 are passed to eth3 with out cheching vlan tags! this is due to bridge between eth3 and eth4! but I don't know how to correct the scenario that eth3 packets to be not tagged through eth4 without disturbing the function of other parts! I would be very glad if someone help me on this important problem I've encountered. On 3/11/12, h bagade wrote: > let me explain my problem with this type of topology when I want to > simulate a switch like cisco > > > > eth1 -+ --- bridge1 --- vlan9 --+-- eth0 --- trunk0 > | > eth2 -+ --- bridge2 --- vlan8 --+ > > On 3/6/12, Peter Jeremy wrote: >> On 2012-Mar-06 09:15:57 +0330, h bagade wrote: >>>On 3/6/12, Peter Jeremy wrote: The following example diagram shows 3 distinct packet flows: - packets tagged 5 in trunk1 and 6 in trunk0 - packets tagged 7 in trunk1 and 9 in trunk0 - packets tagged 8 in trunk0 and 10 in trunk2 +-- vlan5 --- bridge1 --- vlan6 --+ | | trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 | bridge3 --- vlan8 --+ | trunk2 -- eth2 --- vlan10 >>>I've described the function of Cisco switches in vlan >>>tagging/untagging. >> >> Real switches typically have everything tagged internally, with the >> native VLAN tags added/removed at the ingress/egress ports. This >> simplifies the internal switch logic (at the expense of meaning that >> tags have to be consistent across all trunks). >> >> FreeBSD works differently. Packets are _untagged_ internally and you >> need a separate bridge(4) device for each broadcast domain (vlan). >> >>> In your topology, packets should be tagged when >>>recieved on real interfaces to be send out to vlan interfaces. >> >> Packets are never tagged by real interfaces and always have tags >> added/removed by vlan devices. >> >>> It >>>would be fine when two trunks are communicating because on both side >>>packets are tagged. But as I mentioned before, Cisco switches receive >>>packets on an interface untagged and then sending packets tagged out >>>of trunk port, based on which interface it receives, >> >> You can connect a physical interface (ethX) directly to a bridge device >> to access untagged packets. Note that I'm not sure whether it is safe >> to access the native VLAN in a trunk in this way. >> >> To continue the above example, >> ifconfig bridge1 addm eth3 >> would result in packets arriving on eth3 leaving tagged as vlan 5 in >> trunk1, vlan 6 in trunk0 and vice versa. >> >> -- >> Peter Jeremy >> > ___ 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: Intel 82574L interface wedging - em7.3.2/8.2-STABLE
On 3/11/2012 5:31 AM, Adrian Chadd wrote:
Are you able to post the patch here?
Maybe Jack can look at what's going on and apply it to the latest
intel ethernet driver.
Adrian
Below is the patch for if_em.c (7.2.3). It simply checks driver's
queue status when the link state changes (inactive -> active) and
start transmit task if queue(s) are not empty.
It also contains stuff I have added to compile on 7 plus some code
for test and diagnostics.
Hope it helps.
--- if_em.c.orig2011-10-27 14:47:20.0 +0330
+++ if_em.c2011-11-19 16:11:54.0 +0330
@@ -85,6 +85,14 @@
#include "e1000_82571.h"
#include "if_em.h"
+#if !defined(DISABLE_FIXUPS) && __FreeBSD_version < 80
+static __inline int
+pci_find_cap(device_t dev, int capability, int *capreg)
+{
+return (PCI_FIND_EXTCAP(device_get_parent(dev), dev, capability,
capreg));
+}
+#endif
+
/*
* Set this to one to display debug statistics
*/
@@ -93,7 +101,11 @@
/*
* Driver version:
*/
+#ifdef PKG_VERSION
+char em_driver_version[] = "version 7.2.3 (ifdrivers-" PKG_VERSION ")";
+#else
char em_driver_version[] = "7.2.3";
+#endif
/*
* PCI Device ID Table
@@ -293,6 +305,11 @@
static poll_handler_t em_poll;
#endif /* POLLING */
+#ifndef DISABLE_FIXUPS
+static int em_sysctl_snd_ifq_len(SYSCTL_HANDLER_ARGS);
+static int em_sysctl_snd_ifq_drv_len(SYSCTL_HANDLER_ARGS);
+#endif
+
/*
* FreeBSD Device Interface Entry Points
*/
@@ -399,6 +416,23 @@
/* Global used in WOL setup with multiport cards */
static int global_quad_port_a = 0;
+#ifndef DISABLE_FIXUPS
+static int enable_hang_fixup = 1;
+TUNABLE_INT("hw.em.enable_hang_fixup", &enable_hang_fixup);
+SYSCTL_INT(_hw_em, OID_AUTO, enable_hang_fixup, CTLFLAG_RW,
&enable_hang_fixup, 0,
+"Enable rx/tx hang fixup");
+
+static int em_regard_tx_link_status = 1;
+TUNABLE_INT("hw.em.regard_tx_link_status", &em_regard_tx_link_status);
+SYSCTL_INT(_hw_em, OID_AUTO, regard_tx_link_status, CTLFLAG_RW,
&em_regard_tx_link_status, 0,
+"Regard tx link status");
+
+static int link_master_slave = e1000_ms_hw_default;
+TUNABLE_INT("hw.em.link_master_slave", &link_master_slave);
+SYSCTL_INT(_hw_em, OID_AUTO, link_master_slave, CTLFLAG_RW, &link_master_slave,
+0, "Link negotiation master/slave type");
+#endif
+
/*
* Device identification routine
*
@@ -411,7 +445,11 @@
static int
em_probe(device_t dev)
{
+#ifdef PKG_VERSION
+charadapter_name[sizeof(em_driver_version) + 60];
+#else
charadapter_name[60];
+#endif
u16pci_vendor_id = 0;
u16pci_device_id = 0;
u16pci_subvendor_id = 0;
@@ -864,7 +902,11 @@
int err = 0, enq = 0;
if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) !=
+#ifndef DISABLE_FIXUPS
IFF_DRV_RUNNING || adapter->link_active == 0) {
+#else
+IFF_DRV_RUNNING || (em_regard_tx_link_status &&
!adapter->link_active)) {
+#endif
if (m != NULL)
err = drbr_enqueue(ifp, txr->br, m);
return (err);
@@ -962,9 +1004,17 @@
if ((ifp->if_drv_flags & (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=
IFF_DRV_RUNNING)
return;
+#ifdef _TEST
+if (adapter->forced_link_status == 0)
+return;
+#endif
+#ifdef DISABLE_FIXUPS
if (!adapter->link_active)
+#else
+if (em_regard_tx_link_status && !adapter->link_active)
return;
+#endif
while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
/* Call cleanup if number of TX descriptors low */
@@ -977,6 +1027,17 @@
IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head);
if (m_head == NULL)
break;
+#ifdef _TEST
+if (adapter->forced_xmit_error == ENOMEM) {
+ifp->if_drv_flags |= IFF_DRV_OACTIVE;
+IFQ_DRV_PREPEND(&ifp->if_snd, m_head);
+break;
+} else if (adapter->forced_xmit_error != 0) {
+m_freem(m_head);
+m_head = NULL;
+break;
+} else
+#endif
/*
* Encapsulation can modify our pointer, and or make it
* NULL on failure. In that event, we can't requeue.
@@ -1141,6 +1202,10 @@
adapter->hw.phy.reset_disable = FALSE;
/* Check SOL/IDER usage */
EM_CORE_LOCK(adapter);
+#ifndef DISABLE_FIXUPS
+if (adapter->hw.phy.media_type == e1000_media_type_copper)
+adapter->hw.phy.ms_type = link_master_slave;
+#endif
if (e1000_
