[PATCH net-next] vlan: slight optimization for vlan

[PATCH net-next] vlan: slight optimization for vlan

[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.

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 <joe@perches.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
 net/8021q/vlan.c      | 10 +++++-----
 net/8021q/vlan_core.c |  4 ++--
 net/8021q/vlan_dev.c  | 10 +++++-----
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index ec99099..16fb0f4 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -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);
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 6ee48aa..35b3c19 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -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;
 	}
 
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 76d8fab..5e1edd6 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -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:
-- 
1.8.0

Re: [PATCH net-next] vlan: slight optimization for vlan

[Joe Perches]

On Tue, 2014-03-04 at 18:47 +0800, Ding Tianhong wrote:
> 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.

> 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.

Re: [PATCH net-next] vlan: slight optimization for vlan

[David Miller]

From: Ding Tianhong <dingtianhong@huawei.com>
Date: Tue, 4 Mar 2014 18:47:30 +0800

> 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 <joe@perches.com>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>

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

Re: [PATCH net-next] vlan: slight optimization for vlan

[Ding Tianhong]

On 2014/3/4 23:50, Joe Perches wrote:
> On Tue, 2014-03-04 at 18:47 +0800, Ding Tianhong wrote:
>> 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.
> 
>> 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.



>> 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.
> 

OK

Regards
Ding
> 
> 
> 

Re: [PATCH net-next] vlan: slight optimization for vlan

[Ding Tianhong]

On 2014/3/5 9:13, Ding Tianhong wrote:
> On 2014/3/4 23:50, Joe Perches wrote:
>> On Tue, 2014-03-04 at 18:47 +0800, Ding Tianhong wrote:
>>> 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.
>>
>>> 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.
> 
> 
> 
>>> 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

>> I presume a single stream of identical vlan PACKET_OTHERHOST
>> packets is atypical.
>>
> 
> OK
> 
> Regards
> Ding
>>
>>
>>
>