VLAN HW accel, performance advantage?

VLAN HW accel, performance advantage?

[Joakim Tjernlund]

I am considering impl. VLAN HW acceleration in Freescales ucc_geth driver 
to improve
performance, primarily for bridged interfaces.
 I am hoping the community has some insights as to what performance gains 
one
could expect?

   Jocke

Re: VLAN HW accel, performance advantage?

[Ben Hutchings]

On Tue, 2013-09-03 at 11:05 +0200, Joakim Tjernlund wrote:
> I am considering impl. VLAN HW acceleration in Freescales ucc_geth driver 
> to improve
> performance, primarily for bridged interfaces.
>  I am hoping the community has some insights as to what performance gains 
> one
> could expect?

At the moment you need to do VLAN RX offload (or fake it in software) to
take advantage of GRO for VLAN-encapsulated packets.  Other than that, I
don't think it makes a lot of difference in most situations.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: VLAN HW accel, performance advantage?

[Joakim Tjernlund]

Ben Hutchings <bhutchings@solarflare.com> wrote on 2013/09/03 15:50:16:
> 
> On Tue, 2013-09-03 at 11:05 +0200, Joakim Tjernlund wrote:
> > I am considering impl. VLAN HW acceleration in Freescales ucc_geth 
driver 
> > to improve
> > performance, primarily for bridged interfaces.
> >  I am hoping the community has some insights as to what performance 
gains 
> > one
> > could expect?
> 
> At the moment you need to do VLAN RX offload (or fake it in software) to
> take advantage of GRO for VLAN-encapsulated packets.  Other than that, I
> don't think it makes a lot of difference in most situations.
> 
> Ben.

Thanks Ben

I figured one would avoid some memmoves if the tag was extracted and as we 
got
a fairly slow CPU (some 300 MHZ MPC 8321) one should gain some performance 
but not so then.

I am not familiar with GRO( and its friends) but I am guessing it won't 
help
the bridge function or reduce stress from packet storms?

 Jocke
 

Re: VLAN HW accel, performance advantage?

[Ben Hutchings]

On Tue, 2013-09-03 at 16:08 +0200, Joakim Tjernlund wrote:
> Ben Hutchings <bhutchings@solarflare.com> wrote on 2013/09/03 15:50:16:
> > 
> > On Tue, 2013-09-03 at 11:05 +0200, Joakim Tjernlund wrote:
> > > I am considering impl. VLAN HW acceleration in Freescales ucc_geth 
> driver 
> > > to improve
> > > performance, primarily for bridged interfaces.
> > >  I am hoping the community has some insights as to what performance 
> gains 
> > > one
> > > could expect?
> > 
> > At the moment you need to do VLAN RX offload (or fake it in software) to
> > take advantage of GRO for VLAN-encapsulated packets.  Other than that, I
> > don't think it makes a lot of difference in most situations.
> > 
> > Ben.
> 
> Thanks Ben
> 
> I figured one would avoid some memmoves if the tag was extracted and as we 
> got
> a fairly slow CPU (some 300 MHZ MPC 8321) one should gain some performance 
> but not so then.

Of course it will avoid some memmoves, I just don't think that makes
much of a difference any more.  There used to be other more major
performance issues (like having to copy packets) but I believe they've
been fixed in the stack now.

> I am not familiar with GRO( and its friends) but I am guessing it won't 
> help
> the bridge function or reduce stress from packet storms?

GRO should be beneficial for bridges if you have bursty TCP streams.  It
is especially beneficial if you also have TSO on the TX side.

Really you're going to have to try it and run benchmarks with your own
hardware.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: VLAN HW accel, performance advantage?

[Eric Dumazet]

On Tue, 2013-09-03 at 15:48 +0100, Ben Hutchings wrote:

> GRO should be beneficial for bridges if you have bursty TCP streams.  It
> is especially beneficial if you also have TSO on the TX side.
> 
> Really you're going to have to try it and run benchmarks with your own
> hardware.

Note that ucc_geth does not have GRO support (it calls
netif_receive_skb())

It doesnt have RX checksuming either, so having to validate
tcp checksums (before aggregating them in GRO stack) would hurt if
packets only have to be forwarded.

Re: VLAN HW accel, performance advantage?

[Joakim Tjernlund]

Eric Dumazet <eric.dumazet@gmail.com> wrote on 2013/09/03 17:29:10:
> 
> On Tue, 2013-09-03 at 15:48 +0100, Ben Hutchings wrote:
> 
> > GRO should be beneficial for bridges if you have bursty TCP streams. 
It
> > is especially beneficial if you also have TSO on the TX side.
> > 
> > Really you're going to have to try it and run benchmarks with your own
> > hardware.
> 
> Note that ucc_geth does not have GRO support (it calls
> netif_receive_skb())
> 
> It doesnt have RX checksuming either, so having to validate
> tcp checksums (before aggregating them in GRO stack) would hurt if
> packets only have to be forwarded.

Yes, the controller only have IP header checksum. Seems there is little to
gain with HW VLAN support for this controller, maybe when I got some spare 
time
then. :)

Thanks guys

  Jocke