Re: kern/121257: [tcp] TSO + natd -> slow outgoing tcp traffic

[Nick Christenson]

The following reply was made to PR kern/121257; it has been noted by GNATS.

From: Nick Christenson 
To: bug-follo...@freebsd.org, vn...@vnovy.net
Cc:  
Subject: Re: kern/121257: [tcp] TSO + natd -> slow outgoing tcp
 traffic
Date: Sat, 30 Oct 2010 14:03:13 -0700 (PDT)

 I notice that not much has been done on this bug in the last 
 couple of years, so here's a bump.
 
 I have reproduced this bug on an amd64 machine running FreeBSD 
 7.3-RELEASE-p3 with network cards using the msk driver.  I'm
 running natd and pf.  I'm not the only one who has encountered 
 this.  Other references to what looks like the same problem:
 
 http://lists.freebsd.org/pipermail/freebsd-net/2010-July/025731.html
 http://forums.freebsd.org/showthread.php?t=13900
 http://osdir.com/ml/freebsd.bugs/2002-03/msg00051.html
 http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2010-01/msg00674.html
 http://comments.gmane.org/gmane.os.freebsd.current/127669
(subject "significantly slow IPFW + NATD + amd64)
 
 Many of these don't include resolutions, so if this can't be
 fixed, at least publicizing the work around would seem to be 
 well advised.
 
 It sounds from the bug like the developers have a good handle
 on the problem, but if I can do anything to help test, let me 
 know.
 
 -- 
 Nick Christenson
 n...@gangofone.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: Polling slows down bandwidth

[Ed Maste]

On Sat, Oct 30, 2010 at 12:32:19PM +0100, Paul Thornton wrote:

> I've been doing testing with FreeBSD 8 and em interfaces recently, and
> my experience agrees with Chuck's statement - that polling makes things
> worse when you use new (anything in the last 2 or 3 years) hardware with
> good quality gigabit ethernet interfaces.

There are some deficiencies in the current polling algorithm that will
cause it to perform less than optimally (it will temporarily stop
processing packets even though it is consuming less CPU than requested).
I have some changes that I plan to bring into the tree to improve this
situation.  For recent high quality hardware though I expect you'll get
roughly equivalent performance from polling and standard opteration.

-Ed
___
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[2]: Polling slows down bandwidth

[Коньков Евгений]

Hi, Larry.


LB> Also make sure kern.polling.idle_poll is enabled.  By default it is
LB> disabled.  This makes a big difference in polling throughput.

enabling that take all CPU time.

last pid: 38722;  load averages:  1.88,  1.18,  0.85up 1+18:43:28  20:04:54
101 processes: 5 running, 74 sleeping, 22 waiting
CPU:  1.4% user,  0.0% nice, 61.7% system, 36.8% interrupt,  0.0% idle
Mem: 395M Active, 898M Inact, 288M Wired, 5636K Cache, 213M Buf, 388M Free
Swap: 4063M Total, 4063M Free

  PID USERNAME   PRI NICE   SIZERES STATETIME   WCPU COMMAND
   51 root   171 ki31 0K16K RUN  0:56 39.89% idlepoll
   14 root   -44- 0K16K WAIT 3:50 30.47% swi1: net
2 root   -68- 0K16K sleep  253:55 25.20% ng_queue0
17358 bind440   223M   184M RUN 14:30  0.39% named
 1324 root440 31828K  9192K select   9:35  0.29% mpd5
   55 root20- 0K16K syncer   5:18  0.29% syncer

How that affect other processes? Will they be slowed down by idlepoll?

-- 
С уважением,
 Коньков  mailto:kes-...@yandex.ru

___
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[2]: How to obtain place of low perfomance?

[Коньков Евгений]

Hello, Pyun.

Вы писали 29 октября 2010 г., 21:17:45:

PY> On Fri, Oct 29, 2010 at 10:20:10AM +0300, ?? ?? 
wrote:
>> Hi, Freebsd-net.
>> 
>> serv1# ifocnfig nfe0
>> nfe0: flags=8943 metric 0 
>> mtu 1500
>> options=10b
>> ether 00:13:d4:ce:82:16
>> inet 10.11.8.17 netmask 0xfc00 broadcast 10.11.11.255
>> inet 10.11.8.15 netmask 0xfc00 broadcast 10.11.11.255
>> media: Ethernet autoselect (1000baseTX )
>> status: active
>> serv1# ifconfig igb0
>> igb0: flags=8843 metric 0 mtu 1500
>> options=19b
>> ether 00:1b:21:45:da:b8
>> media: Ethernet autoselect (1000baseTX )
>> status: active
>> serv1# ifconfig vlan7
>> vlan7: flags=8843 metric 0 mtu 1500
>> options=3
>> ether 00:1b:21:45:da:b8
>> inet 10.11.15.15 netmask 0xff00 broadcast 10.11.15.255
>> inet 10.11.7.1 netmask 0xff00 broadcast 10.11.7.255
>> media: Ethernet autoselect (1000baseTX )
>> status: active
>> vlan: 7 parent interface: igb0
>> 
>> doing bw test with iperf it show low performance on nfe0.
>> 
>> # iperf -c 10.11.8.17
>> 
>> Client connecting to 10.11.8.17, TCP port 5001
>> TCP window size: 32.5 KByte (default)
>> 
>> [  3] local 10.11.8.16 port 63911 connected with 10.11.8.17 port 5001
>> [ ID] Interval   Transfer Bandwidth
>> [  3]  0.0-10.5 sec124 MBytes  98.8 Mbits/sec
>> # iperf -c 10.11.7.1
>> 
>> Client connecting to 10.11.7.1, TCP port 5001
>> TCP window size: 32.5 KByte (default)
>> 
>> [  3] local 10.11.7.2 port 61422 connected with 10.11.7.1 port 5001
>> [ ID] Interval   Transfer Bandwidth
>> [  3]  0.0-10.3 sec800 MBytes653 Mbits/sec
>> 
>> despite on it is integrated I expect about 300-400Mbit throughput
>> does nfe0 really so poor NIC?

PY> nfe(4) controllers would not be one of best controllers targeted
PY> for server environments but generally it's not poor for desktop
PY> users. I mean you should be able to saturate link when you use bulk
PY> TCP/UDP transfers.
PY> Last time I tried iperf it was not reliable. Did you disable
PY> threading of iperf? Also note, both sender/receiver of iperf should
PY> be built with same configuration option.

igb and nfe on same machine.
   --\igb 10.11.7.1
CLIENT/   SERVER
  \--/nfe 10.11.8.17

-- 
С уважением,
 Коньков  mailto:kes-...@yandex.ru

___
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: em driver problem on vmware

[Ricky Charlet]

Ah, Thanks for the direction. I'll take it as a self project from here. And 
I'll update this thread with my results hopefully by mid next week.

Ricky


From: Jack Vogel [mailto:jfvo...@gmail.com]
Sent: Saturday, October 30, 2010 1:41 AM
To: Juli Mallett
Cc: Ricky Charlet; FreeBSD Net
Subject: Re: em driver problem on vmware

Uh, the emulated device in vmware is an OLD 82543 or something like that right?
So, the e1000 driver in 8.1 is split into two parts, em and lem, its lem that 
has
all the old pci support, so if you only pulled if_em then  you dont have that 
code.

Sounds like maybe you should just install 8.1 on your guest and avoid these
kinds of problems.

Regards,

Jack

On Fri, Oct 29, 2010 at 11:26 PM, Juli Mallett 
mailto:jmall...@freebsd.org>> wrote:
dmesg is not cleared at boot; your devices are not being detected,
they merely showed up in a previous boot.

On Fri, Oct 29, 2010 at 23:13, Ricky  Charlet 
mailto:rchar...@adaranet.com>> wrote:
> Hi Julie,
>
>  My entire dmesg output is attached.
>
> With much appreciation
>
> Ricky
>
>
>
>> -Original Message-
>> From: j...@clockworksquid.com 
>> [mailto:j...@clockworksquid.com] On
>> Behalf Of Juli Mallett
>> Sent: Friday, October 29, 2010 8:01 PM
>> To: Ricky Charlet
>> Subject: Re: em driver problem on vmware
>>
>> Can you send me your full dmesg?  You must be missing some relevant
>> message, because the only circumstances under which you'd see the
>> device attaching but then it wouldn't be present would also generate
>> some error messages.
>>
>> On Fri, Oct 29, 2010 at 19:22, Ricky  Charlet 
>> mailto:rchar...@adaranet.com>>
>> wrote:
>> > Thanks Jack,
>> >
>> >The failure is that ifconfig is unaware of em0.  My
>> em0 is not configured, so link partners are also unaware of it.
>> > ifconfig em0
>> > ifconfig: interface em0 does not exist
>> >
>> > and you already have my dmes stuff on em0 (which I am now up to
>> agreeing looks positive and would not indicate a problem)
>> >
>> >
>> > My amalgamated file is a private combination of some 8.1, some 9.0,
>> some stuff a cohort did.  We have been motivated to 'upgrade' from
>> e1000 in 8.0 to a newer/modified e1000 because of our desire to
>> incorporate the altq patches.
>> >
>> >For the curious and the diligent, the e1000/if_em.c
>> file I am using is attached.
>> >
>> > Ricky
>> >
>> >
>> > From: Jack Vogel [mailto:jfvo...@gmail.com]
>> > Sent: Friday, October 29, 2010 7:13 PM
>> > To: Ricky Charlet
>> > Cc: freebsd-net@freebsd.org
>> > Subject: Re: em driver problem on vmware
>> >
>> > I remember seeing the same thing when running a FreeBSD guest on
>> > Linux/KVM, its informational, the code will enable said bits right
>> after
>> > it says that.
>> >
>> > So, the focus should be on the data, you are saying the delivered
>> > driver in 8.0 out of the box works and which driver exactly are you
>> > trying to use, my last checked in?
>> >
>> > More on the failure,  does it ping, does its link partner see
>> anything,
>> > etc, etc..
>> >
>> > Jack
>> >
>> > On Fri, Oct 29, 2010 at 6:27 PM, Ricky Charlet
>> mailto:rchar...@adaranet.com>>>
>>  wrote:
>> > FYI,
>> > That dmesg output I get from my franken-driver on vmware is exactly
>> the same output I get from the *working* bsd80Release on vmware:
>> >
>> > cut
>> > [r...@npx7511 /usr/src/sys/dev/e1000]# dmesg | grep em0
>> > em0:  port 0x2000-0x203f
>> mem 0xd894-0xd895,0xd890-0xd890 irq 18 at device 0.0 on
>> pci2
>> > em0: Memory Access and/or Bus Master bits were not set!
>> > em0: [FILTER]
>> > em0: Ethernet address: 00:0c:29:57:d7:7f
>> > ---paste---
>> >
>> >
>> > So I don't think the clue is hiding in dmesg.
>> >
>> > ---
>> > Ricky Charlet
>> > Adara Networks
>> > USA 408-433-4942
>> >
>> > -Original Message-
>> > From: 
>> > owner-freebsd-...@freebsd.org
>> n...@freebsd.org> 
>> [mailto:owner-freebsd-...@freebsd.org
>> freebsd-net@freebsd.org>] On Behalf Of Ricky 
>> Charlet
>> > Sent: Friday, October 29, 2010 5:07 PM
>> > To: 
>> > freebsd-net@freebsd.org>
>> > Subject: em driver problem on vmware
>> >
>> > Howdy,
>> >   I have freebsd80-release with an upgraded em0 driver from
>> freebsd8.1 (and an appropriate touch of if_var.h). I'm running an amd64
>> on a  vmware vm.  And I see this in dmesg:
>> >
>> > cut-
>> > em0:  port 0x2000-203f
>> mem 0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0

How to enable/disable flow control on em(4)?

[Eduardo Meyer]

Hellow,

How do I enable/disable flow control on em driver just like I do on
with igb hw.igb.fc_setting?

If it can't be done via settings, is there any change I can on driver
code to get this flag off?

-- 
===
Eduardo Meyer
pessoal: dudu.me...@gmail.com
profissional: ddm.farmac...@saude.gov.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: Polling slows down bandwidth

[Paul Thornton]

Hi,

On 29/10/2010 18:23, Chuck Swiger wrote:
> On Oct 28, 2010, at 11:39 PM, Коньков Евгений wrote:
>> so using polling on gigabit NICs is a bottle neck? and is cause of low 
>> performance, is not?
> 
> Simple answer is yes.  It should be possible that you could tune polling to 
> get similar performance, or at least better performance than you see now, but 
> the additional hardware capabilities of gigabit NICs are likely to outperform 
> polling mode, just as polling mode can generally outperform old 100MBs 
> ethernet NICs.

I have been using polling for a long time with em and fxp interfaces on
6.2 and 4.9 boxes that are working as routers.

I've been doing testing with FreeBSD 8 and em interfaces recently, and
my experience agrees with Chuck's statement - that polling makes things
worse when you use new (anything in the last 2 or 3 years) hardware with
good quality gigabit ethernet interfaces.

I've only really worked with bge and em but they have good high
performance without polling in 8.0 and 8.1

Paul.
___
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: em driver problem on vmware

[Jack Vogel]

Uh, the emulated device in vmware is an OLD 82543 or something like that
right?
So, the e1000 driver in 8.1 is split into two parts, em and lem, its lem
that has
all the old pci support, so if you only pulled if_em then  you dont have
that code.

Sounds like maybe you should just install 8.1 on your guest and avoid these
kinds of problems.

Regards,

Jack


On Fri, Oct 29, 2010 at 11:26 PM, Juli Mallett  wrote:

> dmesg is not cleared at boot; your devices are not being detected,
> they merely showed up in a previous boot.
>
> On Fri, Oct 29, 2010 at 23:13, Ricky  Charlet 
> wrote:
> > Hi Julie,
> >
> >  My entire dmesg output is attached.
> >
> > With much appreciation
> >
> > Ricky
> >
> >
> >
> >> -Original Message-
> >> From: j...@clockworksquid.com [mailto:j...@clockworksquid.com] On
> >> Behalf Of Juli Mallett
> >> Sent: Friday, October 29, 2010 8:01 PM
> >> To: Ricky Charlet
> >> Subject: Re: em driver problem on vmware
> >>
> >> Can you send me your full dmesg?  You must be missing some relevant
> >> message, because the only circumstances under which you'd see the
> >> device attaching but then it wouldn't be present would also generate
> >> some error messages.
> >>
> >> On Fri, Oct 29, 2010 at 19:22, Ricky  Charlet 
> >> wrote:
> >> > Thanks Jack,
> >> >
> >> >The failure is that ifconfig is unaware of em0.  My
> >> em0 is not configured, so link partners are also unaware of it.
> >> > ifconfig em0
> >> > ifconfig: interface em0 does not exist
> >> >
> >> > and you already have my dmes stuff on em0 (which I am now up to
> >> agreeing looks positive and would not indicate a problem)
> >> >
> >> >
> >> > My amalgamated file is a private combination of some 8.1, some 9.0,
> >> some stuff a cohort did.  We have been motivated to 'upgrade' from
> >> e1000 in 8.0 to a newer/modified e1000 because of our desire to
> >> incorporate the altq patches.
> >> >
> >> >For the curious and the diligent, the e1000/if_em.c
> >> file I am using is attached.
> >> >
> >> > Ricky
> >> >
> >> >
> >> > From: Jack Vogel [mailto:jfvo...@gmail.com]
> >> > Sent: Friday, October 29, 2010 7:13 PM
> >> > To: Ricky Charlet
> >> > Cc: freebsd-net@freebsd.org
> >> > Subject: Re: em driver problem on vmware
> >> >
> >> > I remember seeing the same thing when running a FreeBSD guest on
> >> > Linux/KVM, its informational, the code will enable said bits right
> >> after
> >> > it says that.
> >> >
> >> > So, the focus should be on the data, you are saying the delivered
> >> > driver in 8.0 out of the box works and which driver exactly are you
> >> > trying to use, my last checked in?
> >> >
> >> > More on the failure,  does it ping, does its link partner see
> >> anything,
> >> > etc, etc..
> >> >
> >> > Jack
> >> >
> >> > On Fri, Oct 29, 2010 at 6:27 PM, Ricky Charlet
> >> mailto:rchar...@adaranet.com>> wrote:
> >> > FYI,
> >> > That dmesg output I get from my franken-driver on vmware is exactly
> >> the same output I get from the *working* bsd80Release on vmware:
> >> >
> >> > cut
> >> > [r...@npx7511 /usr/src/sys/dev/e1000]# dmesg | grep em0
> >> > em0:  port 0x2000-0x203f
> >> mem 0xd894-0xd895,0xd890-0xd890 irq 18 at device 0.0 on
> >> pci2
> >> > em0: Memory Access and/or Bus Master bits were not set!
> >> > em0: [FILTER]
> >> > em0: Ethernet address: 00:0c:29:57:d7:7f
> >> > ---paste---
> >> >
> >> >
> >> > So I don't think the clue is hiding in dmesg.
> >> >
> >> > ---
> >> > Ricky Charlet
> >> > Adara Networks
> >> > USA 408-433-4942
> >> >
> >> > -Original Message-
> >> > From: owner-freebsd-...@freebsd.org >> n...@freebsd.org> [mailto:owner-freebsd-...@freebsd.org >> freebsd-net@freebsd.org>] On Behalf Of Ricky Charlet
> >> > Sent: Friday, October 29, 2010 5:07 PM
> >> > To: freebsd-net@freebsd.org
> >> > Subject: em driver problem on vmware
> >> >
> >> > Howdy,
> >> >   I have freebsd80-release with an upgraded em0 driver from
> >> freebsd8.1 (and an appropriate touch of if_var.h). I'm running an amd64
> >> on a  vmware vm.  And I see this in dmesg:
> >> >
> >> > cut-
> >> > em0:  port 0x2000-203f
> >> mem 0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0
> >> on pci2
> >> > em0: Memory Access and/or Bus Master bits were not set
> >> > em0: [FILTER]
> >> > em0: Ethernet address: 00:0c:29:57:d7:7f
> >> > paste
> >> >
> >> >   Now, I certainly may have done something wrong with my code
> >> switch (just copied over the sys/dev/e1000 directory from 8.1 and
> >> defined drbr_needs_enqueue in if_var.h). I'll start double checking.
> >> >
> >> >   But, on the other hand, has anyone seen the new em driver
> >> working/failing on a vmware vm?
> >> >
> >> >
> >> > Thanks
> >> >
> >> >
> >> > ---
> >> > Ricky Charlet
> >> > Adara Networks
> >> > USA 408-433-4942
> >>