Re: [RFC] qeth: exploit gro for layer 3 driver

[Blaschka <frank.blaschka@de.ibm.com>]

On Thu, Jan 21, 2010 at 03:35:27PM +0100, Jan Glauber wrote:
> On Thu, 2010-01-21 at 06:03 -0800, David Miller wrote:
> > From: Blaschka <frank.blaschka@de.ibm.com>
> > Date: Thu, 21 Jan 2010 14:48:45 +0100
> > 
> > > So the qeth driver can not disable qdio IRQs (I guess this is a
> > > major reason why not using NAPI) and poll the data.
> > 
> > Just because you cannot stop the events from coming in
> > doesn't mean you can't just queue them up in software
> > or similar.
> 
> The data is already queued (since qdio stands for queued direct I/O).
> Currently qdio gets the interrupt, does some processing and
> tells qeth which buffers contain the new data.
> 
> So the only question is what needs to be different for NAPI
> regarding the event signaling.
> 
> --Jan
> 
Hi Jan,
with some qdio changes we may be able to support NAPI. Let's
checkout what we can do ...

Dave, thanks for the feedback

  Frank

> > The important bits you get are:
> > 
> > 1) RX ring depletion and packet processing all from software
> >    interrupt context
> > 
> > 2) transparent GRO support, without the generic code having
> >    to disclose most of the GRO internals to drivers
> > 
> > I think it can be done.
> > 
> > I have a similar issue as your's with the Sun virtualized network
> > driver (I can't really stop the hypervisor events from pouring in) on
> > sparc64 and I plan to add NAPI support to it.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-s390" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-s390" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html