Skip to contentSkip to conversation

netdevice ops

RFC Stephen Hemminger 5 participants 9 messages May 18, 2007 – May 19, 2007

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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.

#1 lore raw
Quoted 12 lines · 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.

Quoted 5 lines

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

Quoted 5 lines

-
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 1 line
Ben Greear <[email protected]> Candela Technologies Inc  http://www.candelatech.com
maintainer
#2 lore raw

From: Ben Greear <[email protected]>
Date: Thu, 17 May 2007 21:23:16 -0700

Quoted 2 lines

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?

#3 lore raw
Quoted 9 lines · David Miller

From: Ben Greear <[email protected]>
Date: Thu, 17 May 2007 21:23:16 -0700

Quoted 2 lines

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

Signature · 1 line
Ben Greear <[email protected]> Candela Technologies Inc  http://www.candelatech.com
maintainer
#4 lore raw
In reply to Stephen Hemminger

From: Stephen Hemminger <[email protected]>
Date: Thu, 17 May 2007 21:07:37 -0700

Quoted 12 lines

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.

Quoted 4 lines

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.

#5 lore raw
In reply to Stephen Hemminger
Quoted 3 lines · 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.

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

Jeff

maintainer
#6 lore raw

From: Jeff Garzik <[email protected]>
Date: Fri, 18 May 2007 00:54:13 -0400

Quoted 6 lines
Quoted 3 lines · 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.

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?

#7 lore raw
Quoted 4 lines · On Thu, 17 May 2007 22:05:29 -0700 (PDT) David Miller <[email protected]>…

From: Jeff Garzik <[email protected]>
Date: Fri, 18 May 2007 00:54:13 -0400

Quoted 1 line

Stephen Hemminger wrote:

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

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.

#8 lore raw
Quoted 4 lines · Stephen Hemminger

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