Re: [dpdk-users] devargs syntax to use MAC address for bond slaves

Re: [dpdk-users] devargs syntax to use MAC address for bond slaves

[Greg O'Rawe]

Hi,

Thanks for the reply. Is such a patch to the bonding PMD feasible?

Thanks
Greg



This message, including attachments, is CONFIDENTIAL. It may also be privileged or otherwise protected by law. If you received this email by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from Enea may be monitored to ensure compliance with internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, a mended, lost or destroyed, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission. Anyone who communicates with us by email accepts these risks.

Re: [dpdk-users] devargs syntax to use MAC address for bond slaves

[Thomas Monjalon]

19/08/2019 17:56, Greg O'Rawe:
> Hi,
> 
> Thanks for the reply. Is such a patch to the bonding PMD feasible?

Probably yes.
You can try to do it, and work with Chas for help.

Re: [dpdk-users] devargs syntax to use MAC address for bond slaves

[Thomas Monjalon]

+Cc Chas, the maintainer of the bonding PMD

10/08/2019 18:42, Thomas Monjalon:
> Hi,
> 
> 08/08/2019 18:28, Greg O'Rawe:
> > Hi,
> > 
> > I'm using DPDK 17.11.5 to bond two interfaces via the vdev syntax, however the two interfaces are on the same NIC and share the same PCI address.
> > 
> > Is there a way to reference them using the devargs syntax by MAC address? It is discussed here https://patches.dpdk.org/patch/33808/
> > 
> > E.g.
> > class=eth,mac=00:11:22:33:44:55
> > 
> > I don't see this as an option in the bond PMD for slave interfaces even in the latest 19.05 release.
> 
> It is implemented at ethdev level as a port iterator:
> 	http://git.dpdk.org/dpdk/commit/?id=8b9ea3b3ca
> 
> > I'm trying to set this using VPP e.g. normally:
> > vdev eth_bond0,mode=1,slave=PCI1,slave=PCI2
> 
> In order to use this syntax with bonding slaves,
> I think a patch is required.

Re: [dpdk-users] devargs syntax to use MAC address for bond slaves

[Thomas Monjalon]

Hi,

08/08/2019 18:28, Greg O'Rawe:
> Hi,
> 
> I'm using DPDK 17.11.5 to bond two interfaces via the vdev syntax, however the two interfaces are on the same NIC and share the same PCI address.
> 
> Is there a way to reference them using the devargs syntax by MAC address? It is discussed here https://patches.dpdk.org/patch/33808/
> 
> E.g.
> class=eth,mac=00:11:22:33:44:55
> 
> I don't see this as an option in the bond PMD for slave interfaces even in the latest 19.05 release.

It is implemented at ethdev level as a port iterator:
	http://git.dpdk.org/dpdk/commit/?id=8b9ea3b3ca

> I'm trying to set this using VPP e.g. normally:
> vdev eth_bond0,mode=1,slave=PCI1,slave=PCI2

In order to use this syntax with bonding slaves,
I think a patch is required.

[dpdk-users] devargs syntax to use MAC address for bond slaves

[Greg O'Rawe]

Hi,

I'm using DPDK 17.11.5 to bond two interfaces via the vdev syntax, however the two interfaces are on the same NIC and share the same PCI address.

Is there a way to reference them using the devargs syntax by MAC address? It is discussed here https://patches.dpdk.org/patch/33808/

E.g.
class=eth,mac=00:11:22:33:44:55

I don't see this as an option in the bond PMD for slave interfaces even in the latest 19.05 release.

I'm trying to set this using VPP e.g. normally:
vdev eth_bond0,mode=1,slave=PCI1,slave=PCI2

Thanks
Greg



This message, including attachments, is CONFIDENTIAL. It may also be privileged or otherwise protected by law. If you received this email by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from Enea may be monitored to ensure compliance with internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, a mended, lost or destroyed, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission. Anyone who communicates with us by email accepts these risks.