Luigi Rizzo wrote:
> > > This patch will not make any difference if you have device_polling
> > > enabled, because polling already does this -- queues a small number
> > > of packets (default is max 5 per card) and calls ip_input on them
> > > right away.
> >
> > The problem with this is that it in
On Mon, Nov 18, 2002 at 05:12:56PM -0800, Terry Lambert wrote:
> Luigi Rizzo wrote:
...
> > This patch will not make any difference if you have device_polling
> > enabled, because polling already does this -- queues a small number
> > of packets (default is max 5 per card) and calls ip_input on the
Luigi Rizzo wrote:
> Strictly speaking it is not necessary to get rid of the ipintr()
> code, it will just remain unused, so the relevant part of the patch is
> the direct call of ip_input() instead of schednetisr().
>
> This patch will not make any difference if you have device_polling
> enabled,
Strictly speaking it is not necessary to get rid of the ipintr()
code, it will just remain unused, so the relevant part of the patch is
the direct call of ip_input() instead of schednetisr().
This patch will not make any difference if you have device_polling
enabled, because polling already does t
Probably help if I attach the patch. 8-).
-- Terry
Terry Lambert wrote:
>
> > Well... I have all those stats, but I wasn't wanting to type that
> > much. IIRC, we normally test with 80 byte packets ... they can be UDP
> > or TCP ... we're testing the routing. The box has two interfaces and
>
> Well... I have all those stats, but I wasn't wanting to type that
> much. IIRC, we normally test with 80 byte packets ... they can be UDP
> or TCP ... we're testing the routing. The box has two interfaces and
> we measure the number of PPS that get to the box on the other side.
>
> Without poll
