[antinvidia@gmail.com: some questions about bge(4)]

[MQ]

2006/12/14, Oleg Bulyzhin <oleg at freebsd.org>:
>
> On Thu, Dec 14, 2006 at 12:55:51AM +0000, MQ wrote:
> > 2006/12/12, Oleg Bulyzhin <oleg at freebsd.org>:
> > >
> > >On Wed, Dec 06, 2006 at 11:54:01AM +0300, Gleb Smirnoff wrote:
> > >>   Forwarding to net@ list and to Oleg, who has made polling
> > >> support for bge(4).
> > >>
> > >> ----- Forwarded message from MQ < antinvidia at gmail.com> -----
> > >>
> > >> From: MQ <antinvidia at gmail.com>
> > >> To: glebius at freebsd.org , davidch at broadcom.com
> > >> Subject: some questions about bge(4)
> > >> Date: Sat, 2 Dec 2006 09:32:27 +0000
> > >> Delivered-To: glebius at freebsd.org
> > >> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
> > >>         s=beta; d=gmail.com;
> > >>
> > >h=received:message-id:date:from:to:subject:mime-version:content-type;
> > >>
> >
> >b=ZL3ZZ1zR0mt4LaUN2Rr+jXTPSzQgJYRwLiwKnv95r2UCEids5Wl7oA2BNgicJ2QRG8OalJ7DqY7lM1HBgv0OVTlXOhGQ9aFmKQAuTNi6ueZA817XUacXyViEepnj0oNyYgAnkbaaBO1+nl2Fpb3IxV+MIe575WRlqbglF8kdOek=
> > >
> > >>
> > >> Hi David and Gleb,
> > >>    I'm using several chips whose driver is bge(4). And now I have
> some
> > >> questions about the driver, would you please an answer for me?
> > >>    My confusion is related with some codes in /sys/dev/mii/brgphy.c.
> The
> > >
> > >> bge(4) uses the callout to drive the watchdog. And the
> brgphy_service()
> > >is
> > >> called once per second. It calls brgphy_mii_phy_auto() every 5
> seconds
> > >to
> > >> autonegotiate the media. Normally, it costs about 0.5ms in the first
> > >> function brgphy_service(), and about 5ms when autonegotiation is
> > >proceeded.
> > >
> > >brgphy_mii_phy_auto() is called only if there is no link.
> > >
> > >>    I haven't done streestest on it, consequently I don't know if this
> > >delay
> > >> will cause packets to be dropped. But I've enabled device polling
> with
> > >the
> > >> bge(4) on FreeBSD 6.1-RELEASE. If HZ is set to a high value(e.g.
> 4000),
> > >this
> > >> delay will cause the kern.polling.lost_polls to increase by one or
> two
> > >every
> > >> second. And for about five seconds, the lost poll will increase by at
> > >least
> > >> 16 regularly. So I think this behavior has some impact on the systems
> > >that
> > >> enables device polling. Could we get something to make the bge(4) a
> bit
> > >more
> > >> friendly to the device polling? I don't know if autonegotiation is
> > >really
> > >> needed to be called so frequently when we are connected to a good
> > >network
> > >> environment. Can I modify the interval between two autonegotiations
> to
> > >have
> > >> less lost_polls? However, I have no idea about the long time spent in
> > >the
> > >> brgphy_service(), please take a look at the problem when you have
> enough
> > >> time.
> > >
> > >If you have lost poll it does not guarantee packet loss.
> > >Packets can be retrieved by next poll or even by idle_poll thread.
> > >bge_tick() is doing couple of pci register reads (it's polling phy
> status
> > >and
> > >updates some statistic counters), this why it takes some time.
> > >
> > >Anyway, you are right about too short autonegotiation timer, i'll fix
> it
> > >soon.
> > >
> > >>
> > >> Regards
> > >> MQ
> > >>
> > >> ----- End forwarded message -----
> > >>
> > >> --
> > >> Totus tuus, Glebius.
> > >> GLEBIUS-RIPN GLEB-RIPE
> > >
> > >--
> > >Oleg.
> > >
> > >================================================================
> > >=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg at rinet.ru ===
> > >================================================================
> > >
> > >
> >
> > Oh, I didn't connect to switch in my previous testings, so I didn't
> notice
> > that the brgphy_mii_phy_auto() is called only there is no link. It's my
> > fault. Therefore there won't be a problem with this.
> >
> > By the way, bge_tick() takes about 0.5ms to finish its work, this
> results
> > the lost poll every second when HZ is higher. Lower HZ will limit the
> > performance under heavy traffic, and may result packet loss in that
> > situation. And higher HZ will make a confusing situation that whether we
>
> > have encountered a packet loss? It's really hard to make a decision
> between
> > these two kinds of situation.
>
> IMO, high HZ would not give perfomance gain if you have idle polling on
> (sysctl kern.polling.idle_poll=1 ).
> So it's better to have HZ=1000 & idle polling, than HZ=10000 and idle
> polling
> disabled.
>
> --
> Oleg.
>
> ================================================================
> === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg at rinet.ru ===
> ================================================================
>
>

I see, I'll test when I get enough time and a new box with Broadcom NICs