Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Nov 2012 12:02:09 +0100
From:      Fabien Thomas <fabien.thomas@netasq.com>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        Davide Italiano <davide@freebsd.org>, Ryan Stone <rysto32@gmail.com>, Joe Holden <lists@rewt.org.uk>, Luigi Rizzo <rizzo@iet.unipi.it>, FreeBSD Current <current@freebsd.org>
Subject:   Re: polling's future [was: Re: Dynamic Ticks/HZ]
Message-ID:  <04A8DD03-71B2-4EFA-864B-522F49BF1478@netasq.com>
In-Reply-To: <5098E526.6070101@freebsd.org>
References:  <509758B8.1000409@rewt.org.uk> <CACYV=-HwJ1j2-zDtCtuGNKzdFRJhPsZm6vtFXAVyPSabCXvFEQ@mail.gmail.com> <50975F6F.6010907@rewt.org.uk> <CACYV=-Ef5ij7%2BgqDV9oS3xRyD6Yy2mqDyKqqUZZQ-KsWb_3C3A@mail.gmail.com> <5097898C.9080109@rewt.org.uk> <CAFMmRNwR_XxjnRZvxqew77qNnOTGWrRQnhJkg4u2berL8VCVtw@mail.gmail.com> <20121105163654.GA12870@onelab2.iet.unipi.it> <5097E880.8010001@rewt.org.uk> <20121105165748.GA13098@onelab2.iet.unipi.it> <5098E526.6070101@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
>>=20
>=20
> Hi Luigi,
>=20
> do you agree on polling having outlived its usefulness in the light
> of interrupt moderating NIC's and SMP complications/disadvantages?
>=20
If you have only one interface yes polling is not really necessary.

If you have 10 interfaces the interrupt moderation threshold is hard to =
find
to not saturate the system.
Doing polling at 8000hz in that case is a lot better regarding global =
interrupt level.

The problem is that in the current state polling does not work well and =
people remember
the good old time where polling was better.

rstone@ and myself have made some improvement to polling.

You can find a diff here for 8.3 with updated intel driver :=20
http://people.freebsd.org/~fabient/polling/patch-pollif_8.3_11052012

- support multiqueue for ixgbe, igb, em.
- compat API for old driver
- keep interrupt for link / status
- user core mapping / auto mapping
- deadline to keep cpu available
- integrated to netisr
- deferred packet injection with optional prefetching

Performance are on par with interrupt but you can keep a system alive =
more easily
by accounting all network processing for the deadline (with direct =
dispatch).

Fabien

> And also that in its current state it is providing no benefit, if
> not negative, and that fixing it for the current world-order is major
> undertaking that's not really beneficial considering superior
> alternatives?
>=20
> That nobody is maintaining it and taking care of and fixing the =
frequent
> problem, performance and bug reports?
>=20
> Additionally it misleads people without deep network knowledge to
> compile it into their kernel under wrong assumptions and see a
> degradation of performance, if not other side effects?
>=20
> Under these considerations I propose to remove polling support from
> current and 10.0 in lieu of upcoming superior alternatives (netmap
> enabled features).  It was a great feature in the past but is beyond
> retirement and should live a peaceful live in the attic.
>=20
> --=20
> Andre
>=20
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to =
"freebsd-current-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?04A8DD03-71B2-4EFA-864B-522F49BF1478>