[patch] e1000 / lem handling of TSO defragmentation
Similar to what was done for em in r220254, this patch improves the error handling in lem when a TSO packet has too many segments to DMA. This improves the behavior when either call to bus_dmamap_load_mbuf_sg() returns ENOMEM. Although we don't need to go back and redo any offload calculation in lem, doing it this way reduces code duplication. Comments welcome. -Andrew e1000_tso_defrag.diff Description: Binary data -- Andrew Boyerabo...@averesystems.com ___ 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"
[patch] e1000 stats cleanup
This patch fixes a nit in the em, lem, and igb driver statistics, similar to what I proposed for ixgbe a few days ago. Increment adapter->dropped_pkts instead of if_ierrors because if_ierrors is overwritten by hw stats collection. Comments welcome. -Andrew e1000_stats.diff Description: Binary data -- Andrew Boyerabo...@averesystems.com ___ 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"
[patch] ixgbe stats cleanup
This patch fixes some nits in the ixgbe driver statistics: - Only read FCCRC and FCLAST on 82599+ - Store total_missed_rx in stats.mpctotal, and display it in a sysctl - Don't increment if_opackets and if_ipackets every packet; they're overwritten by hw stats collection - Increment adapter->dropped_pkts instead of if_ierrors; if_ierrors is overwritten by hw stats collection - Include adapter->dropped_pkts in the calculation of if_ierrors - Increment rxr->packets so that AIM works Comments welcome. -Andrew ixgbe_stats.diff Description: Binary data ------ Andrew Boyerabo...@averesystems.com ___ 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: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance
38:30 bsd-15 kernel: partner=(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 02:38:30 bsd-15 kernel: partner.state=d > Jul 10 02:38:30 bsd-15 kernel: maxdelay=0 > Jul 10 02:38:30 bsd-15 kernel: ql0: old pstate 5 > Jul 10 02:38:30 bsd-15 kernel: ql0: new pstate > 1d > Jul 10 02:38:30 bsd-15 kernel: ql1: lacp_sm_mux_timer: aggregator > [(8000,00-0E-1E-04-2C-F0, > 0213,,),(,00-00-00-00-00-00,,,)], pending 1 -> 0 > Jul 10 02:38:30 bsd-15 kernel: ql1: collecting disabled > Jul 10 02:38:30 bsd-15 kernel: ql1: mux_state 1 -> 2 > Jul 10 02:38:30 bsd-15 kernel: ql1: collecting enabled > Jul 10 02:38:30 bsd-15 kernel: ql1: mux_state 2 -> 3 > Jul 10 02:38:30 bsd-15 kernel: ql1: enable distributing on aggregator > [(8000,00-0E-1E-04-2C-F0,0213,,),(,00-00-00-00-00-00,,,)], > nports 0 -> 1 > Jul 10 02:38:30 bsd-15 kernel: lacp_select_active_aggregator: > Jul 10 02:38:30 bsd-15 kernel: > [(8000,00-0E-1E-04-2C-F0,0213,,),(,00-00-00-00-00-00,,,)], > speed=100, nports=1 > Jul 10 02:38:30 bsd-15 kernel: active aggregator changed > Jul 10 02:38:30 bsd-15 kernel: old (none) > Jul 10 02:38:30 bsd-15 kernel: new > [(8000,00-0E-1E-04-2C-F0,0213,,),(,00-00-00 > 00-00-00,,,)] > Jul 10 02:38:30 bsd-15 kernel: Set table 1 with 1 ports > Jul 10 02:38:30 bsd-15 kernel: lacp_suppress_distributing > Jul 10 02:38:30 bsd-15 kernel: ql1: marker transmit, port=15, > sys=00:0e:1e:04:2c:f0, id=1 > Jul 10 02:38:30 bsd-15 kernel: ql0: marker transmit, port=14, > sys=00:0e:1e:04:2c:f0, id=1 > Jul 10 02:38:30 bsd-15 kernel: ql1: mux_state 3 -> 4 > Jul 10 02:38:30 bsd-15 kernel: ql1: lacpdu transmit > Jul 10 02:38:30 bsd-15 kernel: ql0: marker response, port=14, > sys=00:0e:1e:04:2c:f0, id=1 > Jul 10 02:38:30 bsd-15 kernel: actor=(8000,00-0E-1E-04-2C-F0,0213,8000,000F) > Jul 10 02:38:30 bsd-15 kernel: > actor.state=7d > Jul 10 02:38:30 bsd-15 kernel: partner=(,00-00-00-00-00-00,,,) > Jul 10 02:38:30 bsd-15 kernel: > partner.state=3c > Jul 10 02:38:30 bsd-15 kernel: maxdelay=0 > Jul 10 02:38:30 bsd-15 kernel: ql0: collecting enabled > Jul 10 02:38:30 bsd-15 kernel: ql0: mux_state 2 -> 3 > Jul 10 02:38:30 bsd-15 kernel: ql0: enable distributing on aggregator > [(8000,00-0E-1E-04-2C-F0,0213,,),(8000,00-0E-1E-08-05-20,01D3,,)], > nports 0 -> 1 > Jul 10 02:38:30 bsd-15 kernel: lacp_select_active_aggregator: > Jul 10 02:38:30 bsd-15 kernel: > [(8000,00-0E-1E-04-2C-F0,0213,,),(8000,00-0E-1E-08-05-20,01D3,,)], > speed=100, nports=1 > Jul 10 02:38:30 bsd-15 kernel: > [(8000,00-0E-1E-04-2C-F0,0213,,),(,00-00-00-00-00-00,,,)], > speed=100, nports=1 > Jul 10 02:38:30 bsd-15 kernel: active aggregator not changed > Jul 10 02:38:30 bsd-15 kernel: new > [(8000,00-0E-1E-04-2C-F0,0213,,),(,00-00-00-00-00-00,,,)] > Jul 10 02:38:30 bsd-15 kernel: ql0: mux_state 3 -> 4 > Jul 10 02:38:30 bsd-15 kernel: ql0: lacpdu transmit > Jul 10 02:38:30 bsd-15 kernel: actor=(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 02:38:30 bsd-15 kernel: > actor.state=3d > Jul 10 02:38:30 bsd-15 kernel: partner=(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 02:38:30 bsd-15 kernel: > partner.state=1d > Jul 10 02:38:30 bsd-15 kernel: maxdelay=0 > Jul 10 02:38:33 bsd-15 kernel: lacp_transit_expire > ^C > > Let me know if you need more info. > > Thanks > Adarsh > > > -Original Message- > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On > Behalf Of Adarsh Joshi > Sent: Tuesday, July 10, 2012 10:08 AM > To: Andrew Boyer > Cc: freebsd-net@freebsd.org > Subject: RE: lacp lagg port flags do not show correctly resulting in poor > traffic distribution/performance > > Andrew, > > Thanks for the reply. > > The reason for my suspicion on the portflags is thus (extracted from the > ifconfig output in my previous mail): > > System 1: > Laggport: ql1 flags = 18 state = 7D > Laggport: ql0 flags = 1c state = 3D > > System 2: > Laggport: ql1 flags = 1c state = 7D > Laggport: ql0 flags = 18 state = 3D > > I should have explained my setup to you before. Here it is. > Both the ql0 interfaces of the 2 systems are connected using a single cable > and ql1 interfaces of the 2 systems are connected using a single cable. > > System 1 System 2 > ql0 <===> ql0 > ql1 <===> ql1 > > With this setup, I don't think it is possible for ports ql0 to talk to their > partners (each ot
Re: Interface MTU question...
On Jul 12, 2012, at 12:55 PM, Jason Hellenthal wrote:
> Something else to look into ...
>
> # ifconfig lagg0 mtu 1492
> ifconfig: ioctl (set mtu): Invalid argument
>
> This is on stable/8 r238264 when the interface was up/up and down/down
>
> Also attempted on the member interfaces dc0 and dc1
It's disabled by default, but I don't know why. This seems to work for us.
-Andrew
Index: sys/net/if_lagg.c
===
--- sys/net/if_lagg.c (revision 238402)
+++ sys/net/if_lagg.c (working copy)
@@ -752,8 +752,18 @@
break;
case SIOCSIFMTU:
- /* Do not allow the MTU to be changed once joined */
- error = EINVAL;
+ LAGG_WLOCK(sc);
+ SLIST_FOREACH(lp, &sc->sc_ports, lp_entries) {
+ if (!error) {
+ /* Call the base ioctl for each port */
+ error = (*lp->lp_ioctl)(lp->lp_ifp, cmd, data);
+ }
+ }
+ if (!error) {
+ /* Update the aggregate MTU */
+ sc->sc_ifp->if_mtu = ifr->ifr_mtu;
+ }
+ LAGG_WUNLOCK(sc);
break;
default:
------
Andrew Boyerabo...@averesystems.com
___
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: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance
On Jul 9, 2012, at 8:38 PM, Adarsh Joshi wrote: > Hi, > > I am trying to configure lacp lagg interfaces with 2 systems connected back > to back as follows: > > Ifconfig lagg0 create > Ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 netmask > 255.255.255.0 > > Sometimes, the lag interface comes up correctly but sometimes the laggport > flags do not show properly. Instead of 1c, it > shows values of 18. I have seen similar issues reported on various forums > with no solution. > Looking at the lagg driver code and reading the standard, I thought the > laggport flags ( defined in if_lagg.h) are based on the LACP_STATE_BITS in > file ieee8023ad_lacp.h. But the following ifconfig -v output does not make > any sense to me. > > My concern is that when all the interfaces show flags as 1c, the traffic is > distributed across both the interfaces uniformly and I get aggregated > throughput. If not, the traffic flows only on 1 interface. > > Is this a bug? How do I solve this? Or am I doing something wrong? > > I am using Free-BSD 9.0 release. > > System 1: > # ifconfig -v lagg0 >lag id: [(8000,00-0E-1E-08-05-20,0213,,), > (8000,00-0E-1E-04-2C-F0,0213,,)] >laggport: ql1 flags=18 state=7D >[(8000,00-0E-1E-08-05-20,0213,8000,000F), > (,00-00-00-00-00-00,,,)] >laggport: ql0 flags=1c state=3D >[(8000,00-0E-1E-08-05-20,0213,8000,000E), > (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] > > System 2: > > # ifconfig -v lagg0 >lag id: [(8000,00-0E-1E-04-2C-F0,0213,,), > (,00-00-00-00-00-00,,,)] >laggport: ql1 flags=1c state=7D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), > (,00-00-00-00-00-00,,,)] >laggport: ql0 flags=18 state=3D >[(8000,00-0E-1E-04-2C-F0,0213,8000,000E), > (8000,00-0E-1E-08-05-20,0213,8000,000E)] > > > thanks > Adarsh > I don't think you have a port flags problem per se; the flags are correctly displaying the state of the lagg. Your problem is that your systems aren't negotiating the correct lagg configuration. Each tuple after the laggport represents the [(actor state),(partner state)]. Ports ql0 have been able to talk to their partners (each other). Neither ql1 port has seen a response from a partner, though. You could try restarting the state machine on one box with 'ifconfig lagg0 laggproto lacp'. To see the negotiation you'll need to rebuild your kernel with '#define LACP_DEBUG 1' added to the top of sys/net/ieee802.3ad_lacp.c. Or upgrade to a newer stable snapshot that has the net.lacp_debug sysctl and turn it on. Or just turn off LACP. What does it get you in this configuration? Hope this helps, Andrew -- Andrew Boyerabo...@averesystems.com ___ 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: Bad interaction between 82599 hardware RSC and VLANs
Any update on this?
-Andrew
On Jan 13, 2012, at 6:04 PM, Jack Vogel wrote:
> Hey Andrew,
>
> Not heard of this before, but I'll check around.
>
> Jack
>
>
> On Fri, Jan 13, 2012 at 3:01 PM, Andrew Boyer wrote:
> Hello Jack,
> I'm seeing an issue on 82599 controllers. When hardware RSC is used, large
> VLAN packets arrive without the VP bit set, even though the vtag in the
> descriptor is correct. It totally kills the receive performance. Turning
> off hardware RSC in the driver (falling back to software LRO) works fine, as
> does turning off LRO entirely.
>
> I've worked around the problem for now by overriding the VP bit if
> ixgbe_rxeof() finds a valid vtag in the descriptor.
>
> Have you seen this before?
>
> It's not in the latest errata. It almost seems to be the opposite of what
> Ryan reported in November 2010 ("82599 receiving packets with vlan tag=0
> (vlan strip problem)?").
>
> Thanks,
> Andrew
>
> --
> Andrew Boyerabo...@averesystems.com
>
>
>
>
> ___
> 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"
>
--
Andrew Boyerabo...@averesystems.com
___
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: LACP kernel panics: /* unlocking is safe here */
Makes sense to me.
-Andrew
On Apr 7, 2012, at 4:02 AM, Andrew Thompson wrote:
> On 3 April 2012 00:35, John Baldwin wrote:
>> On Friday, March 30, 2012 6:04:24 pm Andrew Boyer wrote:
>>> While investigating a LACP issue, I turned on LACP_DEBUG on a debug kernel.
>> In this configuration it's easy to panic the kernel - just run 'ifconfig
>> lagg0
>> laggproto lacp' on a lagg that's already in LACP mode and receiving LACP
>> messages.
>>>
>>> The problem is that lagg_lacp_detach() drops the lagg wlock (with the
>> comment in the title), which allows incoming LACP messages to get through
>> lagg_input() while the structure is being destroyed in lacp_detach().
>>>
>>> There's a very simple fix, but I don't know if it's the best way to fix it.
>> Resetting the protocol before calling sc_detach causes any further incoming
>> packets to be dropped until the lagg gets reconfigured. Thoughts?
>>
>> This looks sensible.
>
> Changing the order also needs an additional check as LAGG_PROTO_NONE
> no longer means the detach is finished. If one ioctl sleeps then we
> may nullify all the pointers upon wake that have already been set by
> the other ioctl.
>
> Does this look ok?
>
> Index: if_lagg.c
> ===
> --- if_lagg.c (revision 233252)
> +++ if_lagg.c (working copy)
> @@ -950,11 +950,11 @@ lagg_ioctl(struct ifnet *ifp, u_long cmd, caddr_t
> error = EPROTONOSUPPORT;
> break;
> }
> + LAGG_WLOCK(sc);
> if (sc->sc_proto != LAGG_PROTO_NONE) {
> - LAGG_WLOCK(sc);
> + /* Reset protocol first in case detach unlocks */
> + sc->sc_proto = LAGG_PROTO_NONE;
> error = sc->sc_detach(sc);
> - /* Reset protocol and pointers */
> - sc->sc_proto = LAGG_PROTO_NONE;
> sc->sc_detach = NULL;
> sc->sc_start = NULL;
> sc->sc_input = NULL;
> @@ -966,8 +966,11 @@ lagg_ioctl(struct ifnet *ifp, u_long cmd, caddr_t
> sc->sc_lladdr = NULL;
> sc->sc_req = NULL;
> sc->sc_portreq = NULL;
> - LAGG_WUNLOCK(sc);
> + } else if (sc->sc_input != NULL) {
> + /* Still detaching */
> + error = EBUSY;
> }
> + LAGG_WUNLOCK(sc);
> if (error != 0)
> break;
> for (int i = 0; i < (sizeof(lagg_protos) /
--
Andrew Boyerabo...@averesystems.com
___
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"
LACP kernel panics: /* unlocking is safe here */
While investigating a LACP issue, I turned on LACP_DEBUG on a debug kernel. In
this configuration it's easy to panic the kernel - just run 'ifconfig lagg0
laggproto lacp' on a lagg that's already in LACP mode and receiving LACP
messages.
The problem is that lagg_lacp_detach() drops the lagg wlock (with the comment
in the title), which allows incoming LACP messages to get through lagg_input()
while the structure is being destroyed in lacp_detach().
There's a very simple fix, but I don't know if it's the best way to fix it.
Resetting the protocol before calling sc_detach causes any further incoming
packets to be dropped until the lagg gets reconfigured. Thoughts?
Is it safe to just hold on to the lagg wlock across the callout_drain() calls
in lacp_detach()? That's what OpenBSD does.
-Andrew
Index: sys/net/if_lagg.c
===
--- sys/net/if_lagg.c (revision 233707)
+++ sys/net/if_lagg.c (working copy)
@@ -952,9 +952,10 @@
}
if (sc->sc_proto != LAGG_PROTO_NONE) {
LAGG_WLOCK(sc);
+ /* Reset protocol */
+ sc->sc_proto = LAGG_PROTO_NONE;
error = sc->sc_detach(sc);
- /* Reset protocol and pointers */
- sc->sc_proto = LAGG_PROTO_NONE;
+ /* Reset pointers */
sc->sc_detach = NULL;
sc->sc_start = NULL;
sc->sc_input = NULL;
--
Andrew Boyerabo...@averesystems.com
___
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: Assigning multiple IPs in the same network to an interface
On Feb 18, 2012, at 5:39 AM, Damien Fleuriot wrote: > On 2/16/12 3:39 PM, Andrew Boyer wrote: >> >> On Feb 16, 2012, at 8:16 AM, Damien Fleuriot wrote: >> >>> On 2/16/12 8:08 AM, M. V. wrote: >>>> hi everybody, >>>> >>>> i have a problem with setting multiple IPs in the same network in FreeBSD: >>>> >>>> - suppose I assign two new IP addresses in the same network to eth0 with >>>> ifconfig: >>>> #ifconfig eth0 add 192.168.10.1/24 >>>> #ifconfig eth0 add 192.168.10.2/24 >>>> >>>> - everything works fine and the output of "netstat -r" is like what it >>>> should be: >>>> #netstat -r >>>> >>>> 192.168.10.0 eth0 >>>> 192.168.10.1lo0 >>>> 192.168.10.2lo0 >>>> ... >>>> >>>> - but now if I delete first IP address, connection to 192.168.10.0 network >>>> will be gone. and in output of "netstat -r" the route to 192.168.10.0 (via >>>> eth0) is gone: >>>> #ifconfig eth0 delete 192.168.10.1 >>>> >>>> #netstat -r >>>> >>>> >>>> 192.168.10.2lo0 >>>> . >>>> >>>> - am i missing something here? shouldn't the route to the network remain >>>> in routing table (because we still have 192.168.10.2 assigned to >>>> interface)? >>>> >>>> Thanks. >>>> >>> >>> You shouldn't assign your secondary IP with a /24 mask, use /32. >>> >>> You'll run into problems otherwise. >>> >>> As a rule of thumb, your aliases = /32 >>> >> >> M.V. - >> What you are doing should work fine. There were a handful of routing table >> bugs fixed in the last few months that corrected this behavior. The last >> two were just merged to stable/8 yesterday. What release are you running? >> >> -Andrew >> > > This is of interest to me. > > Do these fixes allow one to use say /24 aliases instead of /32 without > running into problems ? > Sorry for the long delay. I'm not aware of any restriction on how many IPs or subnets you can install, as long as the subnets don't conflict. I haven't tried IPv6, though... -Andrew -- Andrew Boyerabo...@averesystems.com ___ 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: Assigning multiple IPs in the same network to an interface
On Feb 16, 2012, at 9:30 AM, Rainer Bredehorn wrote: >> i have a problem with setting multiple IPs in the same network in FreeBSD: >> >> - suppose I assign two new IP addresses in the same network to eth0 with >> ifconfig: >> #ifconfig eth0 add 192.168.10.1/24 >> #ifconfig eth0 add 192.168.10.2/24 >> > Second address should be an alias address. > > ;-) > 'ifconfig add' and 'ifconfig alias' are the same thing. -Andrew -- Andrew Boyerabo...@averesystems.com ___ 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: Assigning multiple IPs in the same network to an interface
On Feb 16, 2012, at 8:16 AM, Damien Fleuriot wrote: > On 2/16/12 8:08 AM, M. V. wrote: >> hi everybody, >> >> i have a problem with setting multiple IPs in the same network in FreeBSD: >> >> - suppose I assign two new IP addresses in the same network to eth0 with >> ifconfig: >> #ifconfig eth0 add 192.168.10.1/24 >> #ifconfig eth0 add 192.168.10.2/24 >> >> - everything works fine and the output of "netstat -r" is like what it >> should be: >> #netstat -r >> >> 192.168.10.0 eth0 >> 192.168.10.1lo0 >> 192.168.10.2lo0 >> ... >> >> - but now if I delete first IP address, connection to 192.168.10.0 network >> will be gone. and in output of "netstat -r" the route to 192.168.10.0 (via >> eth0) is gone: >> #ifconfig eth0 delete 192.168.10.1 >> >> #netstat -r >> >> >> 192.168.10.2lo0 >> . >> >> - am i missing something here? shouldn't the route to the network remain in >> routing table (because we still have 192.168.10.2 assigned to interface)? >> >> Thanks. >> > > You shouldn't assign your secondary IP with a /24 mask, use /32. > > You'll run into problems otherwise. > > As a rule of thumb, your aliases = /32 > M.V. - What you are doing should work fine. There were a handful of routing table bugs fixed in the last few months that corrected this behavior. The last two were just merged to stable/8 yesterday. What release are you running? -Andrew -- Andrew Boyerabo...@averesystems.com ___ 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"
Bad interaction between 82599 hardware RSC and VLANs
Hello Jack,
I'm seeing an issue on 82599 controllers. When hardware RSC is used, large
VLAN packets arrive without the VP bit set, even though the vtag in the
descriptor is correct. It totally kills the receive performance. Turning off
hardware RSC in the driver (falling back to software LRO) works fine, as does
turning off LRO entirely.
I've worked around the problem for now by overriding the VP bit if
ixgbe_rxeof() finds a valid vtag in the descriptor.
Have you seen this before?
It's not in the latest errata. It almost seems to be the opposite of what Ryan
reported in November 2010 ("82599 receiving packets with vlan tag=0 (vlan strip
problem)?").
Thanks,
Andrew
------
Andrew Boyerabo...@averesystems.com
___
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: What is the relationship between Intel and FreeBSD in regards to igb(4)?
On Dec 19, 2011, at 7:03 AM, Michael Tuexen wrote: > On Dec 19, 2011, at 12:01 PM, Tanel Rebane wrote: > >> Kevin and Jack, thank you both for your replies. As you might have guessed, >> I was asking because I'm looking into buying a whole bunch of NIC's and I >> feel much more reassured now. Yet, there is one additional question, as I >> mentioned, I couldn't find much in src/sys/dev/igb, is the source for igb >> to be found elsewhere in the src? > They are in > src/sys/dev/e1000/ > In case this is not clear, the sys/dev/e1000 folder contains three drivers: if_lem.c : legacy 1G cards if_em.c: older 1G cards if_igb.c: newer 1G cards The rest of the files are common code shared among the three drivers. -Andrew ------ Andrew Boyerabo...@averesystems.com ___ 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: Too much interrupts on ixgbe
t; 11 root -68- 0K 248K CPU00 336.2H 17.58% {irq256:
> ix0:que }
> 11 root -68- 0K 248K WAIT3 323.4H 17.09% {irq264:
> ix1:que }
> 11 root -68- 0K 248K WAIT1 323.9H 16.55% {irq262:
> ix1:que }
> 11 root -68- 0K 248K WAIT2 325.6H 16.06% {irq263:
> ix1:que }
> 11 root -68- 0K 248K WAIT0 325.9H 15.77% {irq261:
> ix1:que }
>
> vmstat -i
> -
> r# vmstat -i
> interrupt total rate
> irq19: atapci0 1667110 0
> cpu0: timer 3386721810328
> irq256: ix0:que 0 3395843376329
> irq257: ix0:que 1 2642665824256
> irq258: ix0:que 2 2838302235275
> irq259: ix0:que 3 2176207954211
> irq260: ix0:link 18 0
> irq261: ix1:que 0 282359321 27
> irq262: ix1:que 1 3989170496387
> irq263: ix1:que 2 375956573 36
> irq264: ix1:que 3 3966352151384
> irq265: ix1:link 1 0
> irq266: em0:rx 010283114 0
> irq269: em1:rx 010283114 0
> cpu3: timer 3386697130328
> cpu1: timer 3386709028328
> cpu2: timer 3386700908328
> Total33235920163 3225
>
> netstat
>
> # netstat -I ix0 -w1
>input (ix0) output
> packets errs idrops bytespackets errs bytes colls
>264572 0 0 252383894 253290 0 178845781 0
>266323 0 0 254825280 251277 0 173769218 0
>274462 0 0 265247306 260819 0 181113304 0
>271142 0 0 263263325 253941 0 171694438 0
> ^C
> # netstat -I ix1 -w1
>input (ix1) output
> packets errs idrops bytespackets errs bytes colls
>259427 0 0 183038665 275711 0 262429749 0
>248177 0 0 171479966 264441 0 252993752 0
>255271 0 0 185006000 266886 0 247494148 0
>264543 0 0 190970875 275087 0 259555066 0
> ^C
>
> Tuning on both systems are almost the same
> As You can see, 82598EB card produce about 20 times less interrupts at about
> 10 times more pps.
>
> Please help me to fix the problem...
>
> --
> View this message in context:
> http://freebsd.1045724.n5.nabble.com/Too-much-interrupts-on-ixgbe-tp4931883p4931883.html
> Sent from the freebsd-net mailing list archive at Nabble.com.
> ___
> 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"
--
Andrew Boyerabo...@averesystems.com
___
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: MFC Re: soreceive_stream: issues with O_NONBLOCK
On Jul 12, 2011, at 3:10 AM, Andre Oppermann wrote: > On 11.07.2011 17:15, Andrew Boyer wrote: >> On Jul 8, 2011, at 6:51 AM, Andre Oppermann wrote: >> >>> On 07.07.2011 21:24, Mikolaj Golub wrote: >>>> >>>> On Thu, 07 Jul 2011 12:47:15 +0200 Andre Oppermann wrote: >>>> >>>> AO> Please try this patch: AO> >>>> http://people.freebsd.org/~andre/soreceive_stream.diff-20110707 >>>> >>>> It works for me. No issues detected so far. Thanks. >>> >>> Committed in r223863. Many thanks for testing! >>> >>> -- Andre >> >> Hello Andre, It appears that r197236 was never MFC'd, so soreceive_stream is >> still on by default >> in stable/8. Would you be able to MFC it along with 223839 and 223863? > > soreceive_stream() was never on by default. In fact one had to compile it in > and enable it with a tuneable. > > I plan do the MFC's in a few days. > > -- > Andre My bad, I missed the #if 0's in tcp_usrreq.c. Looking forward to the MFC's to try it out. -Andrew -- Andrew Boyerabo...@averesystems.com ___ 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"
MFC of 218627 (SO_SETFIB 0)
Would someone please MFC r218627 back to stable/8 and stable/7? They are both affected. Thank you, Andrew -- Andrew Boyerabo...@averesystems.com ___ 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"
MFC Re: soreceive_stream: issues with O_NONBLOCK
On Jul 8, 2011, at 6:51 AM, Andre Oppermann wrote: > On 07.07.2011 21:24, Mikolaj Golub wrote: >> >> On Thu, 07 Jul 2011 12:47:15 +0200 Andre Oppermann wrote: >> >> AO> Please try this patch: >> AO> http://people.freebsd.org/~andre/soreceive_stream.diff-20110707 >> >> It works for me. No issues detected so far. Thanks. > > Committed in r223863. Many thanks for testing! > > -- > Andre Hello Andre, It appears that r197236 was never MFC'd, so soreceive_stream is still on by default in stable/8. Would you be able to MFC it along with 223839 and 223863? Thank you, Andrew -- Andrew Boyerabo...@averesystems.com ___ 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"
Fwd: kern/156978: [lagg][patch] Take lagg rlock before checking flags
Can someone please review this and check in the patch? (And MFC it to stable/8?) Thank you, Andrew Begin forwarded message: > From: lini...@freebsd.org > Date: May 12, 2011 10:36:26 AM EDT > To: lini...@freebsd.org, freebsd-b...@freebsd.org, freebsd-net@FreeBSD.org > Subject: Re: kern/156978: [lagg][patch] Take lagg rlock before checking flags > > Synopsis: [lagg][patch] Take lagg rlock before checking flags > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Thu May 12 14:36:20 UTC 2011 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=156978 > ___ > 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" -- Andrew Boyerabo...@averesystems.com ___ 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: ixgbe> vlan addition and removal brings the interfaces down and up
Hello Igor, Sorry for the delay. I'm a little hesitant to share our ixgbe patch to change this behavior because Jack has checked in changes to igb that make me think that our change is not correct. Or, at least, that he's probably working on fixing ixgbe the right way. Jack, are you planning to copy the reorganization of igb_setup_vlan_hw_support() over to ixgbe_setup_vlan_hw_support? -Andrew On Jun 28, 2011, at 4:02 PM, Igor Anishchuk wrote: > Hi Andrew, > > could you please share the patch as I'm dying with this problem. > > What makes it worse is that on a busy router the DOWN/UP of the > interfaces causes the ixgbe card to lose all network access until the > box is rebooted. I can reproduce it easily on a variety of hosts from > both HP and Dell. Therefore a patch that would not cause the card to > reset would help a lot. > > -- Igor > > On Thu, May 19, 2011 at 8:58 PM, Andrew Boyer wrote: >> I have a patch that will fix this. Please give me a little while to clean >> it up, and I will send it out on the list. >> >> -Andrew >> >> On May 19, 2011, at 2:58 AM, Igor Anishchuk wrote: >> >>> Hi All, >>> >>> I've been using Intel E10G42AFDA 10Gbit/s AF DA Dual Port adapters >>> with direct attach cables and there is one thing keeps bothering me. >>> I've been searching the Internet for any information with no luck. I >>> would also assume that the problem is widely known, and I found one >>> related PR kern/141285 but that one was closed unsolved. >>> >>> When a VLAN interface is added or removed to from the ix interfaces >>> the parent interface is briefly brought down and up. This event is >>> visible for all applications and the switches. With my use case I add >>> and remove VLAN interfaces on the fly and the described behavior >>> causes undesired effects, especially for BGP daemons that are >>> configured to monitor one of permanent VLAN interfaces. >>> >>> I use FreeBSD 7-STABLE and the behavior is the same with stock >>> drivers, with 2.2.3 and with 2.3.8 drivers downloaded from Intel web >>> site. I have attempted to disable -vlanhwtag, -vlanhwfilter and >>> -vlanhwtso with no effect. >>> >>> Could someone help me to stop the cards behaving this way? I do not >>> mind some performance penalties, nor running in permanent promiscuous >>> mode. I just want the card to stay up all the time regardless of the >>> vlan interfaces attached to it. >>> >>> Any help, links, patches are much appreciated. >>> >>> Regards, >>> >>> Igor Anishchuk >>> _______ >>> 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" >> >> -- >> Andrew Boyerabo...@averesystems.com >> >> >> >> >> -- Andrew Boyerabo...@averesystems.com ___ 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: ixgbe> vlan addition and removal brings the interfaces down and up
I have a patch that will fix this. Please give me a little while to clean it up, and I will send it out on the list. -Andrew On May 19, 2011, at 2:58 AM, Igor Anishchuk wrote: > Hi All, > > I've been using Intel E10G42AFDA 10Gbit/s AF DA Dual Port adapters > with direct attach cables and there is one thing keeps bothering me. > I've been searching the Internet for any information with no luck. I > would also assume that the problem is widely known, and I found one > related PR kern/141285 but that one was closed unsolved. > > When a VLAN interface is added or removed to from the ix interfaces > the parent interface is briefly brought down and up. This event is > visible for all applications and the switches. With my use case I add > and remove VLAN interfaces on the fly and the described behavior > causes undesired effects, especially for BGP daemons that are > configured to monitor one of permanent VLAN interfaces. > > I use FreeBSD 7-STABLE and the behavior is the same with stock > drivers, with 2.2.3 and with 2.3.8 drivers downloaded from Intel web > site. I have attempted to disable -vlanhwtag, -vlanhwfilter and > -vlanhwtso with no effect. > > Could someone help me to stop the cards behaving this way? I do not > mind some performance penalties, nor running in permanent promiscuous > mode. I just want the card to stay up all the time regardless of the > vlan interfaces attached to it. > > Any help, links, patches are much appreciated. > > Regards, > > Igor Anishchuk > ___ > 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" -- Andrew Boyerabo...@averesystems.com ___ 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 ix (X520) disconnects when manipulating ips?
On Apr 23, 2011, at 12:50 AM, Julian Elischer wrote: > On 4/22/11 5:08 PM, Andrew Boyer wrote: >> Hello Steve and Jack, >> You need to handle the SIOCSIFADDR ioctl or it gets passed up the stack to >> ether_ioctl(). When it goes up the interface gets reset. See the comments >> in em_ioctl() and igb_ioctl(). >> >> We fixed this in ixgbe in our internal tree and it seems to work fine with >> 82598 and 82599. You also need to include opt_inet.h for the INET #define >> to be valid. > > so, what else have you fixed? :-) > >> -Andrew >> Here's a list of suggested improvements that we could give back. I try to only bother Jack if a problem results in a hang or other serious issue. - Add tunables for LRO and HWRSC - Add code in ixgbe_attach() to detect 'disabled' hint (call resource_disabled()) [also useful in e1000!] - Add code in ixgbe_attach() to handle IXGBE_ERR_SFP_NOT_PRESENT returned by ixgbe_init_hw() (set sfp_probe to TRUE) - Add VLAN_HWTSO support when handling SIOCSIFCAP - Call ixgbe_disable_queue() at the beginning of ixgbe_msix_que() - Add code to ixgbe_local_timer() to first call ixgbe_txeof() on every queue before checking the queue status - Rework ixgbe_config_link(); if sfp is TRUE, I think it should just schedule mod_task and let it handle the msf case - Add locking and PHY type detection to ixgbe_handle_link() (to support copper->optical and optical->copper transitions) - Add locking to ixgbe_handle_mod(), detect the PHY type, and only schedule msf_task if multispeed_fiber is true - Add locking to ixgbe_handle_msf() I could provide patches for any item that people are interested in testing / incorporating. Of course Jack still gets the final say on what goes into ixgbe. -Andrew -- Andrew Boyerabo...@averesystems.com ___ 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 ix (X520) disconnects when manipulating ips?
Hello Steve and Jack, You need to handle the SIOCSIFADDR ioctl or it gets passed up the stack to ether_ioctl(). When it goes up the interface gets reset. See the comments in em_ioctl() and igb_ioctl(). We fixed this in ixgbe in our internal tree and it seems to work fine with 82598 and 82599. You also need to include opt_inet.h for the INET #define to be valid. -Andrew On Apr 22, 2011, at 7:06 PM, Steven Hartland wrote: > Just double checked on igb1 on the same machine, adding an alias causes > no loss in network from the primary or existing ip aliases for the nic. > > So this should be eliminating most variables except the driver? > > Regards > Steve > > - Original Message - From: "Jack Vogel" > To: "Steven Hartland" > Cc: ; "Vogel, Jack" > Sent: Friday, April 22, 2011 11:35 PM > Subject: Re: Intel ix (X520) disconnects when manipulating ips? > > >> OK, did some testing, this re-init with link transition will happen on both >> the 1G >> drivers as well as ixgbe, its due to the stack/ioctl behavior when you do >> the >> ifconfig. >> So, what are you comparing this to that DOESN'T do this?? If this were to >> be kept from happening I'm not sure where the responsible code would be >> but I'm pretty sure its not in the driver :) > > > > 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" -- Andrew Boyerabo...@averesystems.com ___ 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: panic: bufwrite: buffer is not busy???
Thank you for the response. This is slightly off-topic for the freebsd-net list, but I was hoping your experience might help me with http://www.freebsd.org/cgi/query-pr.cgi?pr=155421. You can look up commits by number at http://svn.freebsd.org/viewvc/base?view=revision&revision=220257, etc. 220257 is the first commit on 2011-04-02, and 220507 is the last commit on 2011-04-09. I don't see any smoking guns in-between, though. -Andrew On Apr 11, 2011, at 1:07 PM, Flávio wrote: > On Mon, Apr 11, 2011 at 11:18 AM, Andrew Boyer > wrote: >> Would you please elaborate on this? Is that Feb-04-2010 or Apr-02-2010? Do >> you have the before and after commit numbers? >> >> Thank you, >> Andrew >> >> On Apr 11, 2011, at 12:37 AM, Flávio wrote: >> >>> Some patch between 02/04 and 09/09 fixed core dumps so now I can provide >>> real info on those panics: >> >> -- >> Andrew Boyerabo...@averesystems.com >> >> > > Sorry, it was a typo. > > In 2011-04-02 I synced some of my servers with HEAD (yes, I know I > should not use HEAD in a production environment, but I have some 7.2 > servers doing fine, which allow me to test development versions) and > rebuild world but then they started to panic every other day and would > always hang while dumping core > > In 2011-04-09 I resynced and updated my kernel. Yesterday one my > servers with HEAD panicked and dumped core normally, so I assume there > was some patch in that week which fixed the issue. > > Where can I see those commit numbers? > ___ > 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" -- Andrew Boyerabo...@averesystems.com ___ 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/150247: [patch] [ixgbe] Version in -current won't build on 7.x systems
While I understand that's generally the case, it's how Intel supports older releases. The code in -current does support building within older releases (at least 7.X and 8.X), except for the flaws I pointed out. Jack Vogel submitted r217129, r217131, and r217132 to fix this PR, but didn't mark it closed. -Andrew On Feb 21, 2011, at 5:10 AM, Bruce Cran wrote: > The following reply was made to PR kern/150247; it has been noted by GNATS. > > From: Bruce Cran > To: bug-follo...@freebsd.org, > abo...@averesystems.com > Cc: > Subject: Re: kern/150247: [patch] [ixgbe] Version in -current won't build on > 7.x systems > Date: Mon, 21 Feb 2011 10:05:27 + > > We don't support building drivers from -CURRENT within the environment for an > older release. I think the ixgbe driver would need to be backported to 7- > STABLE. > > -- > Bruce Cran > ___ > 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" -- Andrew Boyerabo...@averesystems.com ___ 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"
Check in small patches for ixgbe?
Would someone please check in the patches I submitted under these PRs? kern/150247: [patch] [ixgbe] Version in -current won't build on 7.x systems kern/153772: [ixgbe] [patch] sysctls reference wrong XON/XOFF variables It should only take a minute and I think they're noncontroversial... Thank you, Andrew ------ Andrew Boyerabo...@averesystems.com ___ 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/150247: [patch] [ixgbe] Version in -current won't build on 7.x systems
The following reply was made to PR kern/150247; it has been noted by GNATS.
From: Andrew Boyer
To: bug-follo...@freebsd.org,
Andrew Boyer
Cc:
Subject: Re: kern/150247: [patch] [ixgbe] Version in -current won't build on
7.x systems
Date: Fri, 7 Jan 2011 13:36:15 -0500
The problem has spread to the new file ixv.h:
--- ixv.h 2010-11-26 17:46:32.0 -0500
+++ ixv.h 2011-01-07 13:08:45.0 -0500
@@ -175,7 +175,11 @@
#define VFTA_SIZE 128
=20
/* Offload bits in mbuf flag */
+#if __FreeBSD_version >=3D 80
#define CSUM_OFFLOAD (CSUM_IP|CSUM_TCP|CSUM_UDP|CSUM_SCTP)
+#else
+#define CSUM_OFFLOAD (CSUM_IP|CSUM_TCP|CSUM_UDP)
+#endif
=20
/*
=
**=
***
@@ -400,7 +404,7 @@
#define IXV_TX_LOCK_ASSERT(_sc) mtx_assert(&(_sc)->tx_mtx, =
MA_OWNED)
=20
/* Workaround to make 8.0 buildable */
-#if __FreeBSD_version < 800504
+#if __FreeBSD_version >=3D 80 && __FreeBSD_version < 800504
static __inline int
drbr_needs_enqueue(struct ifnet *ifp, struct buf_ring *br)
{
___
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: Dual-rate transceivers with ixgbe?
On Jun 10, 2010, at 3:59 PM, Alexander Sack wrote:
>
>> One thing that the base driver probably ought to do is not fail in
>> attach if there's an unrecognized SFP+ module. Since we get
>> interrupts on module change (although this doesn't seem to always work
>> *entirely* right in the stock sources, mostly wrt stored values of
>> AUTOC and the like) it should be possible to bring the interface up
>> with the unsupported (and disabled) SFP+ module and do the SFP+ module
>> probing we already do on hot-swap.
>
> Alright, let me see if I can test that. Let me rephrase so I validate
> what you are saying:
>
> The driver can come up with an unsupported module but disable the
> interface (ifconfig shows the interface, etc.).
>
> If you then hot-swap a supported SFP, it should come up then with a
> ifconfig down/up cycle. Right?
>
> As it stand now, if you load the driver with an unsupported module, it
> will not attach at all causing you to reload the entire driver OR
> reboot the box to have it reattach to the other SFP.
>
We use this patch to allow the driver to attach when no module is installed.
This might be a starting point for you. I haven't tested it without all of our
other changes in place so my apologies if it doesn't quite work. We only have
Intel modules around for testing.
-Andrew
--- ixgbe.c 2010-06-10 16:53:08.0 -0400
+++ ixgbe.c 2010-06-10 16:55:26.0 -0400
@@ -566,7 +566,7 @@
} else if (error == IXGBE_ERR_SFP_NOT_SUPPORTED)
device_printf(dev,"Unsupported SFP+ Module\n");
- if (error) {
+ if (error && error != IXGBE_ERR_SFP_NOT_PRESENT) {
error = EIO;
device_printf(dev,"Hardware Initialization Failure\n");
goto err_late;
--- ixgbe_82598.c 2010-06-10 16:53:24.0 -0400
+++ ixgbe_82598.c 2010-06-10 16:56:31.0 -0400
@@ -257,10 +257,6 @@
ret_val = ixgbe_get_sfp_init_sequence_offsets(hw,
&list_offset,
&data_offset);
- if (ret_val != IXGBE_SUCCESS) {
- ret_val = IXGBE_ERR_SFP_NOT_SUPPORTED;
- goto out;
- }
break;
default:
break;
--
Andrew Boyerabo...@averesystems.com
___
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: ixgbe 2.1.7 can't disable LRO on 82599?
All,
The solution was simple. Check to make sure the IFCAP_LRO bit is set before
calling ixgbe_setup_hw_rsc().
-Andrew
--- a/src/sys/dev/ixgbe/ixgbe.c
+++ b/src/sys/dev/ixgbe/ixgbe.c
@@ -3728,6 +3728,9 @@ ixgbe_setup_receive_ring(struct rx_ring *rxr)
** Disable RSC when RXCSUM is off
*/
if ((adapter->hw.mac.type == ixgbe_mac_82599EB) &&
+ (ifp->if_capenable & IFCAP_LRO) &&
(ifp->if_capenable & IFCAP_RXCSUM))
ixgbe_setup_hw_rsc(rxr);
else if (ifp->if_capenable & IFCAP_LRO) {
On May 12, 2010, at 4:29 PM, Jack Vogel wrote:
> Correction, the 82599 is doing HW RSC, I'm sluggish after a good Indian lunch
> :)
>
>
> On Wed, May 12, 2010 at 1:28 PM, Jack Vogel wrote:
> Oh, this is because the 82598 is doing HW RSC which is a different code path
> from the LRO that the 598
> does, and that may be the problem, I will need to look into that. Thanks for
> the report.
>
> And, yes, LRO is a major improvement in 10G performance, as is TSO. Are you
> sure you have no
> alternative to disabling?
>
> Cheers,
>
> Jack
>
>
> On Wed, May 12, 2010 at 12:03 PM, Andrew Boyer
> wrote:
> Hello all,
> I'm using the 2.1.7 version of ixgbe from -CURRENT, backported to FreeBSD
> 7.1. With some fiddling it seems to work on both 82598 and 82599 controllers.
>
> On 82598, 'ifconfig ix0 -lro' causes dev.ix.0.counters.rxr0.lro_queued and
> ...lro_flushed to stop incrementing, as expected. There's also a significant
> throughput hit which would seem to indicate that it took effect.
>
> However, it appears that LRO is always enabled on 82599. 'ifconfig ix0 -lro'
> removes the LRO flag from the port in ifconfig but the ...hw_lro_merge
> counter continues to increase. The throughput reported by the iperf port is
> the same with or without LRO on.
>
> Any advice? Am I misinterpreting something?
>
> Thanks,
> Andrew
>
> P.S. We need to disable LRO because we don't have Appropriate Byte Counting
> support and LRO causes TCP ACK havoc without it.
--
Andrew Boyerabo...@averesystems.com
___
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"
ixgbe 2.1.7 can't disable LRO on 82599?
Hello all, I'm using the 2.1.7 version of ixgbe from -CURRENT, backported to FreeBSD 7.1. With some fiddling it seems to work on both 82598 and 82599 controllers. On 82598, 'ifconfig ix0 -lro' causes dev.ix.0.counters.rxr0.lro_queued and ...lro_flushed to stop incrementing, as expected. There's also a significant throughput hit which would seem to indicate that it took effect. However, it appears that LRO is always enabled on 82599. 'ifconfig ix0 -lro' removes the LRO flag from the port in ifconfig but the ...hw_lro_merge counter continues to increase. The throughput reported by the iperf port is the same with or without LRO on. Any advice? Am I misinterpreting something? Thanks, Andrew P.S. We need to disable LRO because we don't have Appropriate Byte Counting support and LRO causes TCP ACK havoc without it. ------ Andrew Boyerabo...@averesystems.com ___ 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"
Question about MFC for 194760,194813, etc. (ifaddr races)
http://svn.freebsd.org/viewvc/base?view=revision&revision=194760 Hello all, We are currently working with the FreeBSD 7.1 release code as the foundation for our product. The other day I experienced a kernel panic when an ifaddr race condition caused a use-after-free error. It looks like SVN commits 194760, 194813, 194819, etc. address this issue. The original commit message for 194760 says "MFC after: 6 weeks (portions)", but I don't see anything to indicate that the fixes were ever merged back. Is anyone planning / willing to merge this back into the 7.X branches? We would very much appreciate it. It looks like there are about two dozen related commits and the diffs don't apply cleanly for me. If it has diverged too much we'll just have to wait until we sync up with 8.0 later this year. Thanks, Andrew ------ Andrew Boyerabo...@averesystems.com ___ 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"
