[RFC] netdevice ops

[RFC] netdevice ops

[Stephen Hemminger]

I want to take all the function pointers of 'struct net_device' and
move them to 'struct net_device_ops'. This will save memory for the
case of lots of devices, as well as reduce initialization code.

Rough plan:
1. Introduce inline accessors so protocols don't dereference dev->XXX directly.
2. Fix protocols to use #1
3. Add ops field to net_device, and netdevice_register will fill in old values
   in 'struct net_device'.
4...1300 Fix all network devices to use ops field
1301 Change accessors to use ops, get rid of old 'struct net_device' function pointers.

It isn't rocket science just another code exercise. I'll patch bomb it into something
like 2.6.23-mm first.

This should really help the people who like to do 1000's of vlans etc.

Re: [RFC] netdevice ops

[Ben Greear]

Stephen Hemminger wrote:
> I want to take all the function pointers of 'struct net_device' and
> move them to 'struct net_device_ops'. This will save memory for the
> case of lots of devices, as well as reduce initialization code.
>
> Rough plan:
> 1. Introduce inline accessors so protocols don't dereference dev->XXX directly.
> 2. Fix protocols to use #1
> 3. Add ops field to net_device, and netdevice_register will fill in old values
>    in 'struct net_device'.
> 4...1300 Fix all network devices to use ops field
> 1301 Change accessors to use ops, get rid of old 'struct net_device' function pointers.
>
> It isn't rocket science just another code exercise. I'll patch bomb it into something
> like 2.6.23-mm first.
>
> This should really help the people who like to do 1000's of vlans etc.
>   
Vlan code uses several of the methods, so I'm not sure how it will save 
any memory unless
you will somehow have a variable sized net_device_ops structure, or 
maybe only move a
certain subset of methods into the ops struct?

Also, this will be a new chunk of memory to keep in cache and 
allocate/deallocate..wouldn't it be more efficient to
keep it local to the netdevice struct?

And there is an extra cost to dereference the point to the ops before 
calling methods?

Thanks,
Ben
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   


-- 
Ben Greear <greearb@candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com

Re: [RFC] netdevice ops

[David Miller]

From: Ben Greear <greearb@candelatech.com>
Date: Thu, 17 May 2007 21:23:16 -0700

> Vlan code uses several of the methods, so I'm not sure how it will save 
> any memory

Feeling particularly dense today?

Only one copy of the ops will be needed for all vlan devices:

static const struct netdev_ops vlan_netdev_ops = {
	...
};

Then VLAN device creation goes, "vlan_netdev->ops = &vlan_netdev_ops;"

Clearer now?

Re: [RFC] netdevice ops

[David Miller]

From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Thu, 17 May 2007 21:07:37 -0700

> I want to take all the function pointers of 'struct net_device' and
> move them to 'struct net_device_ops'. This will save memory for the
> case of lots of devices, as well as reduce initialization code.
> 
> Rough plan:
> 1. Introduce inline accessors so protocols don't dereference dev->XXX directly.
> 2. Fix protocols to use #1
> 3. Add ops field to net_device, and netdevice_register will fill in old values
>    in 'struct net_device'.
> 4...1300 Fix all network devices to use ops field
> 1301 Change accessors to use ops, get rid of old 'struct net_device' function pointers.
> 
> It isn't rocket science just another code exercise. I'll patch bomb it into something
> like 2.6.23-mm first.
> 
> This should really help the people who like to do 1000's of vlans etc.

 I have no objections.

Re: [RFC] netdevice ops

[Jeff Garzik]

Stephen Hemminger wrote:
> I want to take all the function pointers of 'struct net_device' and
> move them to 'struct net_device_ops'. This will save memory for the
> case of lots of devices, as well as reduce initialization code.

It will also add an additional deref to every operation, right?

	Jeff

Re: [RFC] netdevice ops

[David Miller]

From: Jeff Garzik <jgarzik@pobox.com>
Date: Fri, 18 May 2007 00:54:13 -0400

> Stephen Hemminger wrote:
> > I want to take all the function pointers of 'struct net_device' and
> > move them to 'struct net_device_ops'. This will save memory for the
> > case of lots of devices, as well as reduce initialization code.
> 
> It will also add an additional deref to every operation, right?

Yes, it's certainly going to.  How much do we think that actually
matters?

Re: [RFC] netdevice ops

[Stephen Hemminger]

On Thu, 17 May 2007 22:05:29 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Jeff Garzik <jgarzik@pobox.com>
> Date: Fri, 18 May 2007 00:54:13 -0400
> 
> > Stephen Hemminger wrote:
> > > I want to take all the function pointers of 'struct net_device' and
> > > move them to 'struct net_device_ops'. This will save memory for the
> > > case of lots of devices, as well as reduce initialization code.
> > 
> > It will also add an additional deref to every operation, right?
> 
> Yes, it's certainly going to.  How much do we think that actually
> matters?

I would think a non-conditional deref would be easily pipelined.
If the net_device struct was more cache dense, it probably would
even out.

Re: [RFC] netdevice ops

[Ben Greear]

David Miller wrote:
> From: Ben Greear <greearb@candelatech.com>
> Date: Thu, 17 May 2007 21:23:16 -0700
>
>   
>> Vlan code uses several of the methods, so I'm not sure how it will save 
>> any memory
>>     
>
> Feeling particularly dense today?
>   
Ahh, yes indeed.

Ben

-- 
Ben Greear <greearb@candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com

Re: [RFC] netdevice ops

[Andi Kleen]

Stephen Hemminger <shemminger@linux-foundation.org> writes:
> 
> I would think a non-conditional deref would be easily pipelined.
> If the net_device struct was more cache dense, it probably would
> even out.

It might be a good idea to consider strategic prefetch points for it.

e.g. TCP executes quite a lot of code until it finally decides to dev_queue_xmit.
Prefetching before that might be a good idea.

-Andi