DPDK patches and discussions
 help / color / mirror / Atom feed
From: Declan Doherty <declan.doherty@intel.com>
To: Kyle Larose <klarose@sandvine.com>,
	"users@dpdk.org" <users@dpdk.org>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] active_backup link bonding and mac address
Date: Fri, 12 May 2017 16:46:52 +0100	[thread overview]
Message-ID: <8f0580c1-532c-83c5-df4b-68bdbb3a5a05@intel.com> (raw)
In-Reply-To: <D76BBBCF97F57144BB5FCF08007244A7705D4B95@wtl-exchp-1.sandvine.com>

On 12/05/2017 4:34 PM, Kyle Larose wrote:
>
>
>> -----Original Message-----
>> From: Declan Doherty [mailto:declan.doherty@intel.com]
>> Sent: Friday, May 12, 2017 10:56 AM
>> To: Kyle Larose; users@dpdk.org; dev@dpdk.org
>> Subject: Re: active_backup link bonding and mac address
>>
>> On 12/05/2017 3:31 PM, Kyle Larose wrote:
>>> I'm adding the dev mailing list/link bonding maintainer, because I've done
>> some more investigation and I'm beginning to think something is wrong.
>>>
>>
>> Kyle, sorry I didn't see the post in the users list. I think the issue is
>> that the new primary is missing the bond MAC address on it's valid MACs
>> list, hence it is dropping the ingress packets after a fail-over event,
>> placing the all the slave devices into promiscuous mode as you suggest in
>> option 2 would probably make the issue go away but I don't think it's the
>> correct solution. I think we should just be adding the bond MAC to each
>> slaves devices valid MAC list. As only one bond slave is only active at any
>> time this won't cause any issues to the network, and will mean that fail
>> over is transparent to your application and there is no need for MAC
>> rewrites, which would invalidate existing ARP table entries at downstream
>> end points.
>
> Hey Declan,
>
> Thanks for the prompt response.
>
> I agree with your suggestion. Does this MAC list propagate to the slave NICs' hardware layers?
> That is, even if a slave isn't in promiscuous mode, if it receives a frame addressed to any
> MAC in its list, it will accept it and deliver it to the software? Or, does it mean we need to
> put the slave into promiscuous mode, but filter any MACs not in its list (unless the bond
> interface itself is in promiscuous mode)?
>
> Thanks,
>
> Kyle
>

Yes it would be into the hw tables, rte_eth_dev_mac_addr_add() on each 
slave port should achieve this, so there will be no need to run in 
promiscuous mode. I'll try and setup a test for this on Monday morning 
in our lab.

Declan

  reply	other threads:[~2017-05-12 15:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-12 14:31 Kyle Larose
2017-05-12 14:55 ` Declan Doherty
2017-05-12 15:34   ` Kyle Larose
2017-05-12 15:46     ` Declan Doherty [this message]
2017-05-12 19:02       ` Kyle Larose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8f0580c1-532c-83c5-df4b-68bdbb3a5a05@intel.com \
    --to=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=klarose@sandvine.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).