[net-next,v2,RESEND,1/4] macvlan: support mac address changes when fwd_priv is enable

Message ID 1402127143-6456-2-git-send-email-dingtianhong@huawei.com
State New
Headers show

Commit Message

Ding Tianhong June 7, 2014, 7:45 a.m.
If lowerdev supports L2 forwarding offload, the macvlan's hw address
will be set to the rar of the lowerdev and no need to set uc list,
and when the macvlan's hw address changes, the macvlan should remove
the old fwd and rebuild a new fwd for the macvlan.

Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
 drivers/net/macvlan.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

Comments

Vlad Yasevich June 9, 2014, 4:51 p.m. | #1
[.. CC John Fastabend <john.r.fastabend@intel.com> ]

On 06/07/2014 03:45 AM, Ding Tianhong wrote:
> If lowerdev supports L2 forwarding offload, the macvlan's hw address
> will be set to the rar of the lowerdev and no need to set uc list,
> and when the macvlan's hw address changes, the macvlan should remove
> the old fwd and rebuild a new fwd for the macvlan.
> 
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
>  drivers/net/macvlan.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index 453d55a..67485ab 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -523,6 +523,27 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
>  		if (macvlan_addr_busy(vlan->port, addr))
>  			return -EBUSY;
>  
> +		if (vlan->fwd_priv) {
> +			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
> +								   vlan->fwd_priv);
> +			vlan->fwd_priv = NULL;
> +			ether_addr_copy(dev->perm_addr, dev->dev_addr);
> +			ether_addr_copy(dev->dev_addr, addr);
> +			vlan->fwd_priv =
> +			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
> +								       dev);
> +			/* If we get a NULL pointer back, or if we get an error
> +			 * then we should restore the old mac address and fwd.
> +			 */
> +			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
> +				ether_addr_copy(dev->dev_addr, dev->perm_addr);
> +				vlan->fwd_priv =
> +				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
> +									       dev);
> +				return -EINVAL;
> +			}
> +			return 0;
> +		}

Calling del_stations add_station causes all sorts of VMDQ/ring
operations to happen...  Not sure if we can do that while we have a live
macvlan/macvtap that is capable of transmitting data.

Wouldn't it be sufficient to have a call to call to update with mac
filter with the appropriate VMDQ.

John, I defer to you here.  The above looks really heavy-weight and
I am not sure if its correct.

Thanks
-vlad

>  		if (!vlan->port->passthru) {
>  			err = dev_uc_add(lowerdev, addr);
>  			if (err)
> 

--
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
Ding Tianhong June 12, 2014, 1:45 a.m. | #2
On 2014/6/10 0:51, Vlad Yasevich wrote:
> [.. CC John Fastabend <john.r.fastabend@intel.com> ]
> 
> On 06/07/2014 03:45 AM, Ding Tianhong wrote:
>> If lowerdev supports L2 forwarding offload, the macvlan's hw address
>> will be set to the rar of the lowerdev and no need to set uc list,
>> and when the macvlan's hw address changes, the macvlan should remove
>> the old fwd and rebuild a new fwd for the macvlan.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>>  drivers/net/macvlan.c | 21 +++++++++++++++++++++
>>  1 file changed, 21 insertions(+)
>>
>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>> index 453d55a..67485ab 100644
>> --- a/drivers/net/macvlan.c
>> +++ b/drivers/net/macvlan.c
>> @@ -523,6 +523,27 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
>>  		if (macvlan_addr_busy(vlan->port, addr))
>>  			return -EBUSY;
>>  
>> +		if (vlan->fwd_priv) {
>> +			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
>> +								   vlan->fwd_priv);
>> +			vlan->fwd_priv = NULL;
>> +			ether_addr_copy(dev->perm_addr, dev->dev_addr);
>> +			ether_addr_copy(dev->dev_addr, addr);
>> +			vlan->fwd_priv =
>> +			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>> +								       dev);
>> +			/* If we get a NULL pointer back, or if we get an error
>> +			 * then we should restore the old mac address and fwd.
>> +			 */
>> +			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
>> +				ether_addr_copy(dev->dev_addr, dev->perm_addr);
>> +				vlan->fwd_priv =
>> +				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>> +									       dev);
>> +				return -EINVAL;
>> +			}
>> +			return 0;
>> +		}
> 
> Calling del_stations add_station causes all sorts of VMDQ/ring
> operations to happen...  Not sure if we can do that while we have a live
> macvlan/macvtap that is capable of transmitting data.
> 
> Wouldn't it be sufficient to have a call to call to update with mac
> filter with the appropriate VMDQ.
> 
> John, I defer to you here.  The above looks really heavy-weight and
> I am not sure if its correct.
> 
> Thanks
> -vlad

I have used two 82599 nic to test this problem, I modify the ixgbe drivers and set the  L2 forwarding offload default,
without this patch, when I change the macvlan mac address, the kernel oops, and if I apply this patch, the ixgbe could
work well with the maclvan, so I don't think this solution has problem.

Thanks
Ding

> 
>>  		if (!vlan->port->passthru) {
>>  			err = dev_uc_add(lowerdev, addr);
>>  			if (err)
>>
> 
> 
> .
> 


--
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
Vlad Yasevich June 12, 2014, 2:24 p.m. | #3
On 06/11/2014 09:45 PM, Ding Tianhong wrote:
> On 2014/6/10 0:51, Vlad Yasevich wrote:
>> [.. CC John Fastabend <john.r.fastabend@intel.com> ]
>>
>> On 06/07/2014 03:45 AM, Ding Tianhong wrote:
>>> If lowerdev supports L2 forwarding offload, the macvlan's hw address
>>> will be set to the rar of the lowerdev and no need to set uc list,
>>> and when the macvlan's hw address changes, the macvlan should remove
>>> the old fwd and rebuild a new fwd for the macvlan.
>>>
>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>> ---
>>>  drivers/net/macvlan.c | 21 +++++++++++++++++++++
>>>  1 file changed, 21 insertions(+)
>>>
>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>> index 453d55a..67485ab 100644
>>> --- a/drivers/net/macvlan.c
>>> +++ b/drivers/net/macvlan.c
>>> @@ -523,6 +523,27 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
>>>  		if (macvlan_addr_busy(vlan->port, addr))
>>>  			return -EBUSY;
>>>  
>>> +		if (vlan->fwd_priv) {
>>> +			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
>>> +								   vlan->fwd_priv);
>>> +			vlan->fwd_priv = NULL;
>>> +			ether_addr_copy(dev->perm_addr, dev->dev_addr);
>>> +			ether_addr_copy(dev->dev_addr, addr);
>>> +			vlan->fwd_priv =
>>> +			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>> +								       dev);
>>> +			/* If we get a NULL pointer back, or if we get an error
>>> +			 * then we should restore the old mac address and fwd.
>>> +			 */
>>> +			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
>>> +				ether_addr_copy(dev->dev_addr, dev->perm_addr);
>>> +				vlan->fwd_priv =
>>> +				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>> +									       dev);
>>> +				return -EINVAL;
>>> +			}
>>> +			return 0;
>>> +		}
>>
>> Calling del_stations add_station causes all sorts of VMDQ/ring
>> operations to happen...  Not sure if we can do that while we have a live
>> macvlan/macvtap that is capable of transmitting data.
>>
>> Wouldn't it be sufficient to have a call to call to update with mac
>> filter with the appropriate VMDQ.
>>
>> John, I defer to you here.  The above looks really heavy-weight and
>> I am not sure if its correct.
>>
>> Thanks
>> -vlad
> 
> I have used two 82599 nic to test this problem, I modify the ixgbe drivers and set the  L2 forwarding offload default,
> without this patch, when I change the macvlan mac address, the kernel oops, and if I apply this patch, the ixgbe could
> work well with the maclvan, so I don't think this solution has problem.

Have you tried changing the address while at the same time
transmitting data through the macvlan?

-vlad

> 
> Thanks
> Ding
> 
>>
>>>  		if (!vlan->port->passthru) {
>>>  			err = dev_uc_add(lowerdev, addr);
>>>  			if (err)
>>>
>>
>>
>> .
>>
> 
> 

--
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
Ding Tianhong June 13, 2014, 3:10 a.m. | #4
On 2014/6/12 22:24, Vlad Yasevich wrote:
> On 06/11/2014 09:45 PM, Ding Tianhong wrote:
>> On 2014/6/10 0:51, Vlad Yasevich wrote:
>>> [.. CC John Fastabend <john.r.fastabend@intel.com> ]
>>>
>>> On 06/07/2014 03:45 AM, Ding Tianhong wrote:
>>>> If lowerdev supports L2 forwarding offload, the macvlan's hw address
>>>> will be set to the rar of the lowerdev and no need to set uc list,
>>>> and when the macvlan's hw address changes, the macvlan should remove
>>>> the old fwd and rebuild a new fwd for the macvlan.
>>>>
>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>> ---
>>>>  drivers/net/macvlan.c | 21 +++++++++++++++++++++
>>>>  1 file changed, 21 insertions(+)
>>>>
>>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>>> index 453d55a..67485ab 100644
>>>> --- a/drivers/net/macvlan.c
>>>> +++ b/drivers/net/macvlan.c
>>>> @@ -523,6 +523,27 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
>>>>  		if (macvlan_addr_busy(vlan->port, addr))
>>>>  			return -EBUSY;
>>>>  
>>>> +		if (vlan->fwd_priv) {
>>>> +			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
>>>> +								   vlan->fwd_priv);
>>>> +			vlan->fwd_priv = NULL;
>>>> +			ether_addr_copy(dev->perm_addr, dev->dev_addr);
>>>> +			ether_addr_copy(dev->dev_addr, addr);
>>>> +			vlan->fwd_priv =
>>>> +			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>>> +								       dev);
>>>> +			/* If we get a NULL pointer back, or if we get an error
>>>> +			 * then we should restore the old mac address and fwd.
>>>> +			 */
>>>> +			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
>>>> +				ether_addr_copy(dev->dev_addr, dev->perm_addr);
>>>> +				vlan->fwd_priv =
>>>> +				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>>> +									       dev);
>>>> +				return -EINVAL;
>>>> +			}
>>>> +			return 0;
>>>> +		}
>>>
>>> Calling del_stations add_station causes all sorts of VMDQ/ring
>>> operations to happen...  Not sure if we can do that while we have a live
>>> macvlan/macvtap that is capable of transmitting data.
>>>
>>> Wouldn't it be sufficient to have a call to call to update with mac
>>> filter with the appropriate VMDQ.
>>>
>>> John, I defer to you here.  The above looks really heavy-weight and
>>> I am not sure if its correct.
>>>
>>> Thanks
>>> -vlad
>>
>> I have used two 82599 nic to test this problem, I modify the ixgbe drivers and set the  L2 forwarding offload default,
>> without this patch, when I change the macvlan mac address, the kernel oops, and if I apply this patch, the ixgbe could
>> work well with the maclvan, so I don't think this solution has problem.
> 
> Have you tried changing the address while at the same time
> transmitting data through the macvlan?
> 
> -vlad
> 

Yes, I tried, the lowerdev will be closed when calling ixgbe_fwd_del, then the transmitting was broken and about 1 second later,
the transmitting restored and start to work again.

64 bytes from 192.168.10.8: icmp_seq=14 ttl=64 time=0.109 ms
64 bytes from 192.168.10.8: icmp_seq=15 ttl=64 time=0.112 ms
ping: sendmsg: Network is down
64 bytes from 192.168.10.8: icmp_seq=17 ttl=64 time=1000 ms
64 bytes from 192.168.10.8: icmp_seq=18 ttl=64 time=0.147 ms

Ding

>>
>> Thanks
>> Ding
>>
>>>
>>>>  		if (!vlan->port->passthru) {
>>>>  			err = dev_uc_add(lowerdev, addr);
>>>>  			if (err)
>>>>
>>>
>>>
>>> .
>>>
>>
>>
> 
> 
> .
> 


--
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
Vlad Yasevich June 13, 2014, 1:30 p.m. | #5
On 06/12/2014 11:10 PM, Ding Tianhong wrote:
> On 2014/6/12 22:24, Vlad Yasevich wrote:
>> On 06/11/2014 09:45 PM, Ding Tianhong wrote:
>>> On 2014/6/10 0:51, Vlad Yasevich wrote:
>>>> [.. CC John Fastabend <john.r.fastabend@intel.com> ]
>>>>
>>>> On 06/07/2014 03:45 AM, Ding Tianhong wrote:
>>>>> If lowerdev supports L2 forwarding offload, the macvlan's hw address
>>>>> will be set to the rar of the lowerdev and no need to set uc list,
>>>>> and when the macvlan's hw address changes, the macvlan should remove
>>>>> the old fwd and rebuild a new fwd for the macvlan.
>>>>>
>>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>>> ---
>>>>>  drivers/net/macvlan.c | 21 +++++++++++++++++++++
>>>>>  1 file changed, 21 insertions(+)
>>>>>
>>>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>>>> index 453d55a..67485ab 100644
>>>>> --- a/drivers/net/macvlan.c
>>>>> +++ b/drivers/net/macvlan.c
>>>>> @@ -523,6 +523,27 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
>>>>>  		if (macvlan_addr_busy(vlan->port, addr))
>>>>>  			return -EBUSY;
>>>>>  
>>>>> +		if (vlan->fwd_priv) {
>>>>> +			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
>>>>> +								   vlan->fwd_priv);
>>>>> +			vlan->fwd_priv = NULL;
>>>>> +			ether_addr_copy(dev->perm_addr, dev->dev_addr);
>>>>> +			ether_addr_copy(dev->dev_addr, addr);
>>>>> +			vlan->fwd_priv =
>>>>> +			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>>>> +								       dev);
>>>>> +			/* If we get a NULL pointer back, or if we get an error
>>>>> +			 * then we should restore the old mac address and fwd.
>>>>> +			 */
>>>>> +			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
>>>>> +				ether_addr_copy(dev->dev_addr, dev->perm_addr);
>>>>> +				vlan->fwd_priv =
>>>>> +				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>>>> +									       dev);
>>>>> +				return -EINVAL;
>>>>> +			}
>>>>> +			return 0;
>>>>> +		}
>>>>
>>>> Calling del_stations add_station causes all sorts of VMDQ/ring
>>>> operations to happen...  Not sure if we can do that while we have a live
>>>> macvlan/macvtap that is capable of transmitting data.
>>>>
>>>> Wouldn't it be sufficient to have a call to call to update with mac
>>>> filter with the appropriate VMDQ.
>>>>
>>>> John, I defer to you here.  The above looks really heavy-weight and
>>>> I am not sure if its correct.
>>>>
>>>> Thanks
>>>> -vlad
>>>
>>> I have used two 82599 nic to test this problem, I modify the ixgbe drivers and set the  L2 forwarding offload default,
>>> without this patch, when I change the macvlan mac address, the kernel oops, and if I apply this patch, the ixgbe could
>>> work well with the maclvan, so I don't think this solution has problem.
>>
>> Have you tried changing the address while at the same time
>> transmitting data through the macvlan?
>>
>> -vlad
>>
> 
> Yes, I tried, the lowerdev will be closed when calling ixgbe_fwd_del, then the transmitting was broken and about 1 second later,
> the transmitting restored and start to work again.
> 
> 64 bytes from 192.168.10.8: icmp_seq=14 ttl=64 time=0.109 ms
> 64 bytes from 192.168.10.8: icmp_seq=15 ttl=64 time=0.112 ms
> ping: sendmsg: Network is down
> 64 bytes from 192.168.10.8: icmp_seq=17 ttl=64 time=1000 ms
> 64 bytes from 192.168.10.8: icmp_seq=18 ttl=64 time=0.147 ms
> 

Right.  This is what I figured would happen and doesn't happen
with any other device when changing the mac address.

If this behavior is OK with other folks, I'll shut up, but IMO
we shouldn't just correctly update the mac filter and leave the
VMDQs alone.

-vlad

> Ding
> 
>>>
>>> Thanks
>>> Ding
>>>
>>>>
>>>>>  		if (!vlan->port->passthru) {
>>>>>  			err = dev_uc_add(lowerdev, addr);
>>>>>  			if (err)
>>>>>
>>>>
>>>>
>>>> .
>>>>
>>>
>>>
>>
>>
>> .
>>
> 
> 
> --
> 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
> 

--
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
Ding Tianhong June 14, 2014, 5:01 a.m. | #6
On 2014/6/13 21:30, Vlad Yasevich wrote:
> On 06/12/2014 11:10 PM, Ding Tianhong wrote:
>> On 2014/6/12 22:24, Vlad Yasevich wrote:
>>> On 06/11/2014 09:45 PM, Ding Tianhong wrote:
>>>> On 2014/6/10 0:51, Vlad Yasevich wrote:
>>>>> [.. CC John Fastabend <john.r.fastabend@intel.com> ]
>>>>>
>>>>> On 06/07/2014 03:45 AM, Ding Tianhong wrote:
>>>>>> If lowerdev supports L2 forwarding offload, the macvlan's hw address
>>>>>> will be set to the rar of the lowerdev and no need to set uc list,
>>>>>> and when the macvlan's hw address changes, the macvlan should remove
>>>>>> the old fwd and rebuild a new fwd for the macvlan.
>>>>>>
>>>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>>>> ---
>>>>>>  drivers/net/macvlan.c | 21 +++++++++++++++++++++
>>>>>>  1 file changed, 21 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>>>>> index 453d55a..67485ab 100644
>>>>>> --- a/drivers/net/macvlan.c
>>>>>> +++ b/drivers/net/macvlan.c
>>>>>> @@ -523,6 +523,27 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
>>>>>>  		if (macvlan_addr_busy(vlan->port, addr))
>>>>>>  			return -EBUSY;
>>>>>>  
>>>>>> +		if (vlan->fwd_priv) {
>>>>>> +			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
>>>>>> +								   vlan->fwd_priv);
>>>>>> +			vlan->fwd_priv = NULL;
>>>>>> +			ether_addr_copy(dev->perm_addr, dev->dev_addr);
>>>>>> +			ether_addr_copy(dev->dev_addr, addr);
>>>>>> +			vlan->fwd_priv =
>>>>>> +			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>>>>> +								       dev);
>>>>>> +			/* If we get a NULL pointer back, or if we get an error
>>>>>> +			 * then we should restore the old mac address and fwd.
>>>>>> +			 */
>>>>>> +			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
>>>>>> +				ether_addr_copy(dev->dev_addr, dev->perm_addr);
>>>>>> +				vlan->fwd_priv =
>>>>>> +				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>>>>> +									       dev);
>>>>>> +				return -EINVAL;
>>>>>> +			}
>>>>>> +			return 0;
>>>>>> +		}
>>>>>
>>>>> Calling del_stations add_station causes all sorts of VMDQ/ring
>>>>> operations to happen...  Not sure if we can do that while we have a live
>>>>> macvlan/macvtap that is capable of transmitting data.
>>>>>
>>>>> Wouldn't it be sufficient to have a call to call to update with mac
>>>>> filter with the appropriate VMDQ.
>>>>>
>>>>> John, I defer to you here.  The above looks really heavy-weight and
>>>>> I am not sure if its correct.
>>>>>
>>>>> Thanks
>>>>> -vlad
>>>>
>>>> I have used two 82599 nic to test this problem, I modify the ixgbe drivers and set the  L2 forwarding offload default,
>>>> without this patch, when I change the macvlan mac address, the kernel oops, and if I apply this patch, the ixgbe could
>>>> work well with the maclvan, so I don't think this solution has problem.
>>>
>>> Have you tried changing the address while at the same time
>>> transmitting data through the macvlan?
>>>
>>> -vlad
>>>
>>
>> Yes, I tried, the lowerdev will be closed when calling ixgbe_fwd_del, then the transmitting was broken and about 1 second later,
>> the transmitting restored and start to work again.
>>
>> 64 bytes from 192.168.10.8: icmp_seq=14 ttl=64 time=0.109 ms
>> 64 bytes from 192.168.10.8: icmp_seq=15 ttl=64 time=0.112 ms
>> ping: sendmsg: Network is down
>> 64 bytes from 192.168.10.8: icmp_seq=17 ttl=64 time=1000 ms
>> 64 bytes from 192.168.10.8: icmp_seq=18 ttl=64 time=0.147 ms
>>
> 
> Right.  This is what I figured would happen and doesn't happen
> with any other device when changing the mac address.
> 
> If this behavior is OK with other folks, I'll shut up, but IMO
> we shouldn't just correctly update the mac filter and leave the
> VMDQs alone.
> 
> -vlad
> 

Yes, according to your important suggestion, we could further analysis this problem,
and can you explain more about how to fix it better, just like the VMDQ, I am not very
clear about this, thanks for any feedback.

Regards
Ding 

>> Ding
>>
>>>>
>>>> Thanks
>>>> Ding
>>>>
>>>>>
>>>>>>  		if (!vlan->port->passthru) {
>>>>>>  			err = dev_uc_add(lowerdev, addr);
>>>>>>  			if (err)
>>>>>>
>>>>>
>>>>>
>>>>> .
>>>>>
>>>>
>>>>
>>>
>>>
>>> .
>>>
>>
>>
>> --
>> 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
>>
> 
> 
> .
> 


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

Patch

diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 453d55a..67485ab 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -523,6 +523,27 @@  static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
 		if (macvlan_addr_busy(vlan->port, addr))
 			return -EBUSY;
 
+		if (vlan->fwd_priv) {
+			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
+								   vlan->fwd_priv);
+			vlan->fwd_priv = NULL;
+			ether_addr_copy(dev->perm_addr, dev->dev_addr);
+			ether_addr_copy(dev->dev_addr, addr);
+			vlan->fwd_priv =
+			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
+								       dev);
+			/* If we get a NULL pointer back, or if we get an error
+			 * then we should restore the old mac address and fwd.
+			 */
+			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
+				ether_addr_copy(dev->dev_addr, dev->perm_addr);
+				vlan->fwd_priv =
+				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
+									       dev);
+				return -EINVAL;
+			}
+			return 0;
+		}
 		if (!vlan->port->passthru) {
 			err = dev_uc_add(lowerdev, addr);
 			if (err)