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-users] 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
next prev parent reply other threads:[~2017-05-12 15:46 UTC|newest]
Thread overview: 6+ 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
-- strict thread matches above, loose matches on Subject: below --
2017-05-11 20:54 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).