Skip to contentSkip to conversation

vlan: slight optimization for vlan

PATCH In review Ding Tianhong 3 participants 5 messages Mar 4, 2014 – Mar 5, 2014

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Ding Tianhong

author
#0 lore raw

PATCH 1/1 vlan: slight optimization for vlan

Ether_addr_equal_64bits is more efficient than ether_addr_equal, and can be used when each argument is an array within a structure that contains at least two bytes of data beyond the array, so it is safe to use it for vlan.

On a simple test by iperf, it reduces the CPU %system time from 14% to 12%.

According Joe's suggestion, maybe it'd be faster to add an unlikely to the test for PCKET_OTHERHOST, so I add it and see whether the performance could be better, but the differences is so small and negligible, maybe my test case is not effective enough, but I still add the unlikely and wait to hear more opinions.:)

Cc Joe Perches <[email protected]>
Cc Patrick McHardy <[email protected]>
Cc David S. Miller <[email protected]>
Signed-off-by Ding Tianhong <[email protected]>
---
 net/8021q/vlan.c      | 10 +++++-----
 net/8021q/vlan_core.c |  4 ++--
 net/8021q/vlan_dev.c  | 10 +++++-----
 3 files changed, 12 insertions(+), 12 deletions(-)
net/8021q/vlan.c +5 -5
index ec99099..16fb0f4 100644
@@ -286,19 +286,19 @@ static void vlan_sync_address(struct net_device *dev,
 	struct vlan_dev_priv *vlan = vlan_dev_priv(vlandev);
 
 	/* May be called without an actual change */
-	if (ether_addr_equal(vlan->real_dev_addr, dev->dev_addr))
+	if (ether_addr_equal_64bits(vlan->real_dev_addr, dev->dev_addr))
 		return;
 
 	/* vlan address was different from the old address and is equal to
 	 * the new address */
-	if (!ether_addr_equal(vlandev->dev_addr, vlan->real_dev_addr) &&
-	    ether_addr_equal(vlandev->dev_addr, dev->dev_addr))
+	if (!ether_addr_equal_64bits(vlandev->dev_addr, vlan->real_dev_addr) &&
+	    ether_addr_equal_64bits(vlandev->dev_addr, dev->dev_addr))
 		dev_uc_del(dev, vlandev->dev_addr);
 
 	/* vlan address was equal to the old address and is different from
 	 * the new address */
-	if (ether_addr_equal(vlandev->dev_addr, vlan->real_dev_addr) &&
-	    !ether_addr_equal(vlandev->dev_addr, dev->dev_addr))
+	if (ether_addr_equal_64bits(vlandev->dev_addr, vlan->real_dev_addr) &&
+	    !ether_addr_equal_64bits(vlandev->dev_addr, dev->dev_addr))
 		dev_uc_add(dev, vlandev->dev_addr);
 
 	ether_addr_copy(vlan->real_dev_addr, dev->dev_addr);
net/8021q/vlan_core.c +2 -2
index 6ee48aa..35b3c19 100644
@@ -22,11 +22,11 @@ bool vlan_do_receive(struct sk_buff **skbp)
 		return false;
 
 	skb->dev = vlan_dev;
-	if (skb->pkt_type == PACKET_OTHERHOST) {
+	if (unlikely(skb->pkt_type == PACKET_OTHERHOST)) {
 		/* Our lower layer thinks this is not local, let's make sure.
 		 * This allows the VLAN to have a different MAC than the
 		 * underlying device, and still route correctly. */
-		if (ether_addr_equal(eth_hdr(skb)->h_dest, vlan_dev->dev_addr))
+		if (ether_addr_equal_64bits(eth_hdr(skb)->h_dest, vlan_dev->dev_addr))
 			skb->pkt_type = PACKET_HOST;
 	}
net/8021q/vlan_dev.c +5 -5
index 76d8fab..5e1edd6 100644
@@ -286,7 +286,7 @@ static int vlan_dev_open(struct net_device *dev)
 	    !(vlan->flags & VLAN_FLAG_LOOSE_BINDING))
 		return -ENETDOWN;
 
-	if (!ether_addr_equal(dev->dev_addr, real_dev->dev_addr)) {
+	if (!ether_addr_equal_64bits(dev->dev_addr, real_dev->dev_addr)) {
 		err = dev_uc_add(real_dev, dev->dev_addr);
 		if (err < 0)
 			goto out;

@@ -319,7 +319,7 @@ clear_allmulti:
 	if (dev->flags & IFF_ALLMULTI)
 		dev_set_allmulti(real_dev, -1);
 del_unicast:
-	if (!ether_addr_equal(dev->dev_addr, real_dev->dev_addr))
+	if (!ether_addr_equal_64bits(dev->dev_addr, real_dev->dev_addr))
 		dev_uc_del(real_dev, dev->dev_addr);
 out:
 	netif_carrier_off(dev);

@@ -338,7 +338,7 @@ static int vlan_dev_stop(struct net_device *dev)
 	if (dev->flags & IFF_PROMISC)
 		dev_set_promiscuity(real_dev, -1);
 
-	if (!ether_addr_equal(dev->dev_addr, real_dev->dev_addr))
+	if (!ether_addr_equal_64bits(dev->dev_addr, real_dev->dev_addr))
 		dev_uc_del(real_dev, dev->dev_addr);
 
 	netif_carrier_off(dev);

@@ -357,13 +357,13 @@ static int vlan_dev_set_mac_address(struct net_device *dev, void *p)
 	if (!(dev->flags & IFF_UP))
 		goto out;
 
-	if (!ether_addr_equal(addr->sa_data, real_dev->dev_addr)) {
+	if (!ether_addr_equal_64bits(addr->sa_data, real_dev->dev_addr)) {
 		err = dev_uc_add(real_dev, addr->sa_data);
 		if (err < 0)
 			return err;
 	}
 
-	if (!ether_addr_equal(dev->dev_addr, real_dev->dev_addr))
+	if (!ether_addr_equal_64bits(dev->dev_addr, real_dev->dev_addr))
 		dev_uc_del(real_dev, dev->dev_addr);
 
 out:
Signature · 1 line
1.8.0
#1 lore raw
Quoted 4 lines · Ding Tianhong

Ether_addr_equal_64bits is more efficient than ether_addr_equal, and can be used when each argument is an array within a structure that contains at least two bytes of data beyond the array, so it is safe to use it for vlan.

Perhaps I wasn't clear or perhaps you simply disagree, (which is certainly your right), but I think that ether_addr_equal_64bits should _only_ be used in performance sensitive paths because using it requires a person/script to analyze surrounding structures to ensure 2 bytes exist after the address.

I don't think that vlan_dev_(open|stop|set_mac_address) are performance sensitive paths.

vlan_do_receive, absolutely yes.

Is the vlan_device_event:NETDEV_CHANGEADDR:vlan_sync_address path that frequent? Maybe.

Quoted 7 lines

On a simple test by iperf, it reduces the CPU %system time from 14% to 12%.

According Joe's suggestion, maybe it'd be faster to add an unlikely to the test for PCKET_OTHERHOST, so I add it and see whether the performance could be better, but the differences is so small and negligible, maybe my test case is not effective enough, but I still add the unlikely and wait to hear more opinions.:)

A separate patch for the unlikely would likely be better, but I wonder what your test case is.

I presume a single stream of identical vlan PACKET_OTHERHOST packets is atypical.

author
#2 lore raw
Quoted 13 lines · Joe Perches
Quoted 4 lines · Ding Tianhong

Ether_addr_equal_64bits is more efficient than ether_addr_equal, and can be used when each argument is an array within a structure that contains at least two bytes of data beyond the array, so it is safe to use it for vlan.

Perhaps I wasn't clear or perhaps you simply disagree, (which is certainly your right), but I think that ether_addr_equal_64bits should _only_ be used in performance sensitive paths because using it requires a person/script to analyze surrounding structures to ensure 2 bytes exist after the address.

Quoted 10 lines

I don't think that vlan_dev_(open|stop|set_mac_address) are performance sensitive paths.

vlan_do_receive, absolutely yes.

Is the vlan_device_event:NETDEV_CHANGEADDR:vlan_sync_address path that frequent? Maybe.

Quoted 1 line

On a simple test by iperf, it reduces the CPU %system time from 14% to 12%.

Totally agree with you, use the XXX_64bits in slow path make no sense, thanks a lot.

Quoted 6 lines
Quoted 5 lines

According Joe's suggestion, maybe it'd be faster to add an unlikely to the test for PCKET_OTHERHOST, so I add it and see whether the performance could be better, but the differences is so small and negligible, maybe my test case is not effective enough, but I still add the unlikely and wait to hear more opinions.:)

Quoted 6 lines

A separate patch for the unlikely would likely be better, but I wonder what your test case is.

I presume a single stream of identical vlan PACKET_OTHERHOST packets is atypical.

OK

Regards
Ding

Quoted 3 lines
author
#3 lore raw
Quoted 19 lines · Ding Tianhong
Quoted 18 lines · Joe Perches
Quoted 4 lines · Ding Tianhong

Ether_addr_equal_64bits is more efficient than ether_addr_equal, and can be used when each argument is an array within a structure that contains at least two bytes of data beyond the array, so it is safe to use it for vlan.

Perhaps I wasn't clear or perhaps you simply disagree, (which is certainly your right), but I think that ether_addr_equal_64bits should _only_ be used in performance sensitive paths because using it requires a person/script to analyze surrounding structures to ensure 2 bytes exist after the address.

I don't think that vlan_dev_(open|stop|set_mac_address) are performance sensitive paths.

vlan_do_receive, absolutely yes.

Quoted 19 lines
Quoted 5 lines

Is the vlan_device_event:NETDEV_CHANGEADDR:vlan_sync_address path that frequent? Maybe.

Quoted 1 line

On a simple test by iperf, it reduces the CPU %system time from 14% to 12%.

Totally agree with you, use the XXX_64bits in slow path make no sense, thanks a lot.

Quoted 9 lines
Quoted 5 lines

According Joe's suggestion, maybe it'd be faster to add an unlikely to the test for PCKET_OTHERHOST, so I add it and see whether the performance could be better, but the differences is so small and negligible, maybe my test case is not effective enough, but I still add the unlikely and wait to hear more opinions.:)

A separate patch for the unlikely would likely be better, but I wonder what your test case is.

Hi Joe:

My test case is very simple, use iperf to test the vlan dev, and compare the %system time that add unlikely or not, do you have any suggestion for that, or gave me some advise, thanks a lot.

Regards
Ding

Quoted 12 lines
Quoted 3 lines

I presume a single stream of identical vlan PACKET_OTHERHOST packets is atypical.

OK

Regards
Ding

Quoted 3 lines
maintainer
#4 lore raw
In reply to Ding Tianhong

From: Ding Tianhong <[email protected]>
Date: Tue, 4 Mar 2014 18:47:30 +0800

Quoted 13 lines

Ether_addr_equal_64bits is more efficient than ether_addr_equal, and can be used when each argument is an array within a structure that contains at least two bytes of data beyond the array, so it is safe to use it for vlan.

On a simple test by iperf, it reduces the CPU %system time from 14% to 12%.

According Joe's suggestion, maybe it'd be faster to add an unlikely to the test for PCKET_OTHERHOST, so I add it and see whether the performance could be better, but the differences is so small and negligible, maybe my test case is not effective enough, but I still add the unlikely and wait to hear more opinions.:)

Quoted 4 lines
Cc Joe Perches <[email protected]>
Cc Patrick McHardy <[email protected]>
Cc David S. Miller <[email protected]>
Signed-off-by Ding Tianhong <[email protected]>

I agree with Joe that we should only use the optimized routine in performance critical paths.