[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OFF8862166.946F925C-ONC1257A7A.00386AD8-C1257A7A.0042C1CF@transmode.se>
Date: Sat, 15 Sep 2012 14:09:09 +0200
From: Joakim Tjernlund <joakim.tjernlund@...nsmode.se>
To: Stephen Hemminger <shemminger@...tta.com>
Cc: netdev@...r.kernel.org
Subject: Re: interrupt coalescing and CSUM offload
Stephen Hemminger <shemminger@...tta.com> wrote on 2012/09/14 18:32:52:
>
> On Fri, 14 Sep 2012 16:35:13 +0200
> Joakim Tjernlund <joakim.tjernlund@...nsmode.se> wrote:
>
> >
> > I am adding interrupt coalescing to the ucc_geth driver. Unfortunately
> > there is only support for RX interrupt coalescing.
> > I wonder if there is any way "simulate" TX interrupt coalescing?
> >
> > I am also looking at adding HWCSUM support but this device can only do
> > IP header CSUM offload. This doesn't seem to be an option in Linux?
> > As I understand it, one must do CSUM offload for the whole frame, both
> > IP header and TCP/UDP csums?
> >
> > Jocke
>
> There are a few drivers that turn off TX interrupt completely.
> They cleanup TX buffers on next send and have a timer to cleanup
Only on send? Currently ucc_geth does TX free in napi(where RX is processed too).
It would be nice if one could indicate to the drivers xmit() if there
are more frames to be sent. Then xmit() could choose not to turn on TX irq for
preceding frames.
> as well. This has performance benefits, but it does cause issues
> with local flow control (the freeing of skb is used to rate
> limit local traffic).
Was my reasoning correct w.r.t CSUM?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists