<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/tools/testing/selftests/drivers/net, branch linux-6.5.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>selftests: bonding: add macvlan over bond testing</title>
<updated>2023-08-24T08:07:13+00:00</updated>
<author>
<name>Hangbin Liu</name>
<email>liuhangbin@gmail.com</email>
</author>
<published>2023-08-23T07:19:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=246af950b9404da3cb1fed0dc85c7a637be0aff6'/>
<id>246af950b9404da3cb1fed0dc85c7a637be0aff6</id>
<content type='text'>
Add a macvlan over bonding test with mode active-backup, balance-tlb
and balance-alb.

]# ./bond_macvlan.sh
TEST: active-backup: IPv4: client-&gt;server                           [ OK ]
TEST: active-backup: IPv6: client-&gt;server                           [ OK ]
TEST: active-backup: IPv4: client-&gt;macvlan_1                        [ OK ]
TEST: active-backup: IPv6: client-&gt;macvlan_1                        [ OK ]
TEST: active-backup: IPv4: client-&gt;macvlan_2                        [ OK ]
TEST: active-backup: IPv6: client-&gt;macvlan_2                        [ OK ]
TEST: active-backup: IPv4: macvlan_1-&gt;macvlan_2                     [ OK ]
TEST: active-backup: IPv6: macvlan_1-&gt;macvlan_2                     [ OK ]
TEST: active-backup: IPv4: server-&gt;client                           [ OK ]
TEST: active-backup: IPv6: server-&gt;client                           [ OK ]
TEST: active-backup: IPv4: macvlan_1-&gt;client                        [ OK ]
TEST: active-backup: IPv6: macvlan_1-&gt;client                        [ OK ]
TEST: active-backup: IPv4: macvlan_2-&gt;client                        [ OK ]
TEST: active-backup: IPv6: macvlan_2-&gt;client                        [ OK ]
TEST: active-backup: IPv4: macvlan_2-&gt;macvlan_2                     [ OK ]
TEST: active-backup: IPv6: macvlan_2-&gt;macvlan_2                     [ OK ]
[...]
TEST: balance-alb: IPv4: client-&gt;server                             [ OK ]
TEST: balance-alb: IPv6: client-&gt;server                             [ OK ]
TEST: balance-alb: IPv4: client-&gt;macvlan_1                          [ OK ]
TEST: balance-alb: IPv6: client-&gt;macvlan_1                          [ OK ]
TEST: balance-alb: IPv4: client-&gt;macvlan_2                          [ OK ]
TEST: balance-alb: IPv6: client-&gt;macvlan_2                          [ OK ]
TEST: balance-alb: IPv4: macvlan_1-&gt;macvlan_2                       [ OK ]
TEST: balance-alb: IPv6: macvlan_1-&gt;macvlan_2                       [ OK ]
TEST: balance-alb: IPv4: server-&gt;client                             [ OK ]
TEST: balance-alb: IPv6: server-&gt;client                             [ OK ]
TEST: balance-alb: IPv4: macvlan_1-&gt;client                          [ OK ]
TEST: balance-alb: IPv6: macvlan_1-&gt;client                          [ OK ]
TEST: balance-alb: IPv4: macvlan_2-&gt;client                          [ OK ]
TEST: balance-alb: IPv6: macvlan_2-&gt;client                          [ OK ]
TEST: balance-alb: IPv4: macvlan_2-&gt;macvlan_2                       [ OK ]
TEST: balance-alb: IPv6: macvlan_2-&gt;macvlan_2                       [ OK ]

Signed-off-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Acked-by: Jay Vosburgh &lt;jay.vosburgh@canonical.com&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a macvlan over bonding test with mode active-backup, balance-tlb
and balance-alb.

]# ./bond_macvlan.sh
TEST: active-backup: IPv4: client-&gt;server                           [ OK ]
TEST: active-backup: IPv6: client-&gt;server                           [ OK ]
TEST: active-backup: IPv4: client-&gt;macvlan_1                        [ OK ]
TEST: active-backup: IPv6: client-&gt;macvlan_1                        [ OK ]
TEST: active-backup: IPv4: client-&gt;macvlan_2                        [ OK ]
TEST: active-backup: IPv6: client-&gt;macvlan_2                        [ OK ]
TEST: active-backup: IPv4: macvlan_1-&gt;macvlan_2                     [ OK ]
TEST: active-backup: IPv6: macvlan_1-&gt;macvlan_2                     [ OK ]
TEST: active-backup: IPv4: server-&gt;client                           [ OK ]
TEST: active-backup: IPv6: server-&gt;client                           [ OK ]
TEST: active-backup: IPv4: macvlan_1-&gt;client                        [ OK ]
TEST: active-backup: IPv6: macvlan_1-&gt;client                        [ OK ]
TEST: active-backup: IPv4: macvlan_2-&gt;client                        [ OK ]
TEST: active-backup: IPv6: macvlan_2-&gt;client                        [ OK ]
TEST: active-backup: IPv4: macvlan_2-&gt;macvlan_2                     [ OK ]
TEST: active-backup: IPv6: macvlan_2-&gt;macvlan_2                     [ OK ]
[...]
TEST: balance-alb: IPv4: client-&gt;server                             [ OK ]
TEST: balance-alb: IPv6: client-&gt;server                             [ OK ]
TEST: balance-alb: IPv4: client-&gt;macvlan_1                          [ OK ]
TEST: balance-alb: IPv6: client-&gt;macvlan_1                          [ OK ]
TEST: balance-alb: IPv4: client-&gt;macvlan_2                          [ OK ]
TEST: balance-alb: IPv6: client-&gt;macvlan_2                          [ OK ]
TEST: balance-alb: IPv4: macvlan_1-&gt;macvlan_2                       [ OK ]
TEST: balance-alb: IPv6: macvlan_1-&gt;macvlan_2                       [ OK ]
TEST: balance-alb: IPv4: server-&gt;client                             [ OK ]
TEST: balance-alb: IPv6: server-&gt;client                             [ OK ]
TEST: balance-alb: IPv4: macvlan_1-&gt;client                          [ OK ]
TEST: balance-alb: IPv6: macvlan_1-&gt;client                          [ OK ]
TEST: balance-alb: IPv4: macvlan_2-&gt;client                          [ OK ]
TEST: balance-alb: IPv6: macvlan_2-&gt;client                          [ OK ]
TEST: balance-alb: IPv4: macvlan_2-&gt;macvlan_2                       [ OK ]
TEST: balance-alb: IPv6: macvlan_2-&gt;macvlan_2                       [ OK ]

Signed-off-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Acked-by: Jay Vosburgh &lt;jay.vosburgh@canonical.com&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>selftest: bond: add new topo bond_topo_2d1c.sh</title>
<updated>2023-08-24T08:07:13+00:00</updated>
<author>
<name>Hangbin Liu</name>
<email>liuhangbin@gmail.com</email>
</author>
<published>2023-08-23T07:19:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=27aa43f83c83e9243c6959426f6e36cb32aeb2d5'/>
<id>27aa43f83c83e9243c6959426f6e36cb32aeb2d5</id>
<content type='text'>
Add a new testing topo bond_topo_2d1c.sh which is used more commonly.
Make bond_topo_3d1c.sh just source bond_topo_2d1c.sh and add the
extra link.

Signed-off-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Acked-by: Jay Vosburgh &lt;jay.vosburgh@canonical.com&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a new testing topo bond_topo_2d1c.sh which is used more commonly.
Make bond_topo_3d1c.sh just source bond_topo_2d1c.sh and add the
extra link.

Signed-off-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Acked-by: Jay Vosburgh &lt;jay.vosburgh@canonical.com&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>selftests: bonding: do not set port down before adding to bond</title>
<updated>2023-08-22T02:05:42+00:00</updated>
<author>
<name>Hangbin Liu</name>
<email>liuhangbin@gmail.com</email>
</author>
<published>2023-08-17T08:24:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=be809424659c2844a2d7ab653aacca4898538023'/>
<id>be809424659c2844a2d7ab653aacca4898538023</id>
<content type='text'>
Before adding a port to bond, it need to be set down first. In the
lacpdu test the author set the port down specifically. But commit
a4abfa627c38 ("net: rtnetlink: Enslave device before bringing it up")
changed the operation order, the kernel will set the port down _after_
adding to bond. So all the ports will be down at last and the test failed.

In fact, the veth interfaces are already inactive when added. This
means there's no need to set them down again before adding to the bond.
Let's just remove the link down operation.

Fixes: a4abfa627c38 ("net: rtnetlink: Enslave device before bringing it up")
Reported-by: Zhengchao Shao &lt;shaozhengchao@huawei.com&gt;
Closes: https://lore.kernel.org/netdev/a0ef07c7-91b0-94bd-240d-944a330fcabd@huawei.com/
Signed-off-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Link: https://lore.kernel.org/r/20230817082459.1685972-1-liuhangbin@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before adding a port to bond, it need to be set down first. In the
lacpdu test the author set the port down specifically. But commit
a4abfa627c38 ("net: rtnetlink: Enslave device before bringing it up")
changed the operation order, the kernel will set the port down _after_
adding to bond. So all the ports will be down at last and the test failed.

In fact, the veth interfaces are already inactive when added. This
means there's no need to set them down again before adding to the bond.
Let's just remove the link down operation.

Fixes: a4abfa627c38 ("net: rtnetlink: Enslave device before bringing it up")
Reported-by: Zhengchao Shao &lt;shaozhengchao@huawei.com&gt;
Closes: https://lore.kernel.org/netdev/a0ef07c7-91b0-94bd-240d-944a330fcabd@huawei.com/
Signed-off-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Link: https://lore.kernel.org/r/20230817082459.1685972-1-liuhangbin@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>selftests: mlxsw: Fix test failure on Spectrum-4</title>
<updated>2023-08-19T02:41:06+00:00</updated>
<author>
<name>Ido Schimmel</name>
<email>idosch@nvidia.com</email>
</author>
<published>2023-08-17T13:58:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f520489e99a35b0a5257667274fbe9afd2d8c50b'/>
<id>f520489e99a35b0a5257667274fbe9afd2d8c50b</id>
<content type='text'>
Remove assumptions about shared buffer cell size and instead query the
cell size from devlink. Adjust the test to send small packets that fit
inside a single cell.

Tested on Spectrum-{1,2,3,4}.

Fixes: 4735402173e6 ("mlxsw: spectrum: Extend to support Spectrum-4 ASIC")
Signed-off-by: Ido Schimmel &lt;idosch@nvidia.com&gt;
Reviewed-by: Petr Machata &lt;petrm@nvidia.com&gt;
Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://lore.kernel.org/r/f7dfbf3c4d1cb23838d9eb99bab09afaa320c4ca.1692268427.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove assumptions about shared buffer cell size and instead query the
cell size from devlink. Adjust the test to send small packets that fit
inside a single cell.

Tested on Spectrum-{1,2,3,4}.

Fixes: 4735402173e6 ("mlxsw: spectrum: Extend to support Spectrum-4 ASIC")
Signed-off-by: Ido Schimmel &lt;idosch@nvidia.com&gt;
Reviewed-by: Petr Machata &lt;petrm@nvidia.com&gt;
Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://lore.kernel.org/r/f7dfbf3c4d1cb23838d9eb99bab09afaa320c4ca.1692268427.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>selftests: mlxsw: one_armed_router: Use port MAC for bridge address</title>
<updated>2023-06-21T21:02:52+00:00</updated>
<author>
<name>Petr Machata</name>
<email>petrm@nvidia.com</email>
</author>
<published>2023-06-20T13:56:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=664bc72dd20073be227f9e68b3db75313c6926f8'/>
<id>664bc72dd20073be227f9e68b3db75313c6926f8</id>
<content type='text'>
In a future patch, mlxsw will start adding RIFs to uppers of front panel
port netdevices, if they have an IP address.

At the time that the front panel port is enslaved to the bridge, the bridge
MAC address does not have the same prefix as other interfaces in the
system. On Nvidia Spectrum-1 machines all the RIFs have to have the same
38-bit MAC address prefix. Since the bridge does not obey this limitation,
the RIF cannot be created, and the enslavement attempt is vetoed on the
grounds of the configuration not being offloadable.

The bridge eventually inherits MAC address from its first member, after the
enslavement is acked. A number of (mainly VXLAN) selftests already work
around the problem by setting the MAC address to whatever it will
eventually be anyway. Do the same for this selftest.

Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In a future patch, mlxsw will start adding RIFs to uppers of front panel
port netdevices, if they have an IP address.

At the time that the front panel port is enslaved to the bridge, the bridge
MAC address does not have the same prefix as other interfaces in the
system. On Nvidia Spectrum-1 machines all the RIFs have to have the same
38-bit MAC address prefix. Since the bridge does not obey this limitation,
the RIF cannot be created, and the enslavement attempt is vetoed on the
grounds of the configuration not being offloadable.

The bridge eventually inherits MAC address from its first member, after the
enslavement is acked. A number of (mainly VXLAN) selftests already work
around the problem by setting the MAC address to whatever it will
eventually be anyway. Do the same for this selftest.

Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>selftests: mlxsw: vxlan: Disable IPv6 autogen on bridges</title>
<updated>2023-06-21T21:02:52+00:00</updated>
<author>
<name>Petr Machata</name>
<email>petrm@nvidia.com</email>
</author>
<published>2023-06-20T13:56:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5541577521cc2e22bc84ba92be24959671006283'/>
<id>5541577521cc2e22bc84ba92be24959671006283</id>
<content type='text'>
In a future patch, mlxsw will start adding RIFs to uppers of front panel
port netdevices, if they have an IP address.

At the time that the front panel port is enslaved to the bridge (this holds
for all bridges used here), the bridge MAC address does not have the same
prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all
the RIFs have to have the same 38-bit MAC address prefix. Since the bridge
does not obey this limitation, the RIF cannot be created, and the
enslavement attempt is vetoed on the grounds of the configuration not being
offloadable.

The selftest itself however checks various aspects of VXLAN offloading and
the bridges do not need to participate in routing traffic. The IP addresses
or the RIFs are irrelevant.

Fix by disabling automatic IPv6 address generation for the HW-offloaded
bridges in this selftest, thus exempting them from mlxsw router attention.

Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In a future patch, mlxsw will start adding RIFs to uppers of front panel
port netdevices, if they have an IP address.

At the time that the front panel port is enslaved to the bridge (this holds
for all bridges used here), the bridge MAC address does not have the same
prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all
the RIFs have to have the same 38-bit MAC address prefix. Since the bridge
does not obey this limitation, the RIF cannot be created, and the
enslavement attempt is vetoed on the grounds of the configuration not being
offloadable.

The selftest itself however checks various aspects of VXLAN offloading and
the bridges do not need to participate in routing traffic. The IP addresses
or the RIFs are irrelevant.

Fix by disabling automatic IPv6 address generation for the HW-offloaded
bridges in this selftest, thus exempting them from mlxsw router attention.

Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>selftests: mlxsw: spectrum: q_in_vni_veto: Disable IPv6 autogen on a bridge</title>
<updated>2023-06-21T21:02:52+00:00</updated>
<author>
<name>Petr Machata</name>
<email>petrm@nvidia.com</email>
</author>
<published>2023-06-20T13:56:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=08035d8e354d9fc652c9d12668e89d83edc8f974'/>
<id>08035d8e354d9fc652c9d12668e89d83edc8f974</id>
<content type='text'>
In a future patch, mlxsw will start adding RIFs to uppers of front panel
port netdevices, if they have an IP address.

At the time that the front panel port is enslaved to the bridge, the bridge
MAC address does not have the same prefix as other interfaces in the
system. On Nvidia Spectrum-1 machines all the RIFs have to have the same
38-bit MAC address prefix. Since the bridge does not obey this limitation,
the RIF cannot be created, and the enslavement attempt is vetoed on the
grounds of the configuration not being offloadable.

The selftest itself however checks vetoing of a different aspect of the
configuration and the bridge does not need to participate in routing
traffic. The IP address or the RIF are irrelevant.

Fix by disabling automatic IPv6 address generation for the HW-offloaded
bridge in this selftest, thus exempting it from mlxsw router attention.

Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In a future patch, mlxsw will start adding RIFs to uppers of front panel
port netdevices, if they have an IP address.

At the time that the front panel port is enslaved to the bridge, the bridge
MAC address does not have the same prefix as other interfaces in the
system. On Nvidia Spectrum-1 machines all the RIFs have to have the same
38-bit MAC address prefix. Since the bridge does not obey this limitation,
the RIF cannot be created, and the enslavement attempt is vetoed on the
grounds of the configuration not being offloadable.

The selftest itself however checks vetoing of a different aspect of the
configuration and the bridge does not need to participate in routing
traffic. The IP address or the RIF are irrelevant.

Fix by disabling automatic IPv6 address generation for the HW-offloaded
bridge in this selftest, thus exempting it from mlxsw router attention.

Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>selftests: mlxsw: qos_mc_aware: Disable IPv6 autogen on bridges</title>
<updated>2023-06-21T21:02:52+00:00</updated>
<author>
<name>Petr Machata</name>
<email>petrm@nvidia.com</email>
</author>
<published>2023-06-20T13:55:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ea2d5f757e914fa0f82949e130ee9da0ee931e59'/>
<id>ea2d5f757e914fa0f82949e130ee9da0ee931e59</id>
<content type='text'>
In a future patch, mlxsw will start adding RIFs to uppers of front panel
port netdevices, if they have an IP address.

At the time that the front panel port is enslaved to the bridge (this holds
for both bridges used here), the bridge MAC address does not have the same
prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all
the RIFs have to have the same 38-bit MAC address prefix. Since the bridge
does not obey this limitation, the RIF cannot be created, and the
enslavement attempt is vetoed on the grounds of the configuration not being
offloadable.

The selftest itself however checks traffic prioritization and scheduling,
and the bridges serve for their L2 forwarding capabilities, and do not need
to participate in routing traffic. The IP addresses or the RIFs are
irrelevant.

Fix by disabling automatic IPv6 address generation for the HW-offloaded
bridges in this selftest, thus exempting them from mlxsw router attention.

Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In a future patch, mlxsw will start adding RIFs to uppers of front panel
port netdevices, if they have an IP address.

At the time that the front panel port is enslaved to the bridge (this holds
for both bridges used here), the bridge MAC address does not have the same
prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all
the RIFs have to have the same 38-bit MAC address prefix. Since the bridge
does not obey this limitation, the RIF cannot be created, and the
enslavement attempt is vetoed on the grounds of the configuration not being
offloadable.

The selftest itself however checks traffic prioritization and scheduling,
and the bridges serve for their L2 forwarding capabilities, and do not need
to participate in routing traffic. The IP addresses or the RIFs are
irrelevant.

Fix by disabling automatic IPv6 address generation for the HW-offloaded
bridges in this selftest, thus exempting them from mlxsw router attention.

Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>selftests: mlxsw: qos_ets_strict: Disable IPv6 autogen on bridges</title>
<updated>2023-06-21T21:02:52+00:00</updated>
<author>
<name>Petr Machata</name>
<email>petrm@nvidia.com</email>
</author>
<published>2023-06-20T13:55:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ec7023e6745e6fb34cd855522cb8f995194bdbf1'/>
<id>ec7023e6745e6fb34cd855522cb8f995194bdbf1</id>
<content type='text'>
In a future patch, mlxsw will start adding RIFs to uppers of front panel
port netdevices, if they have an IP address.

At the time that the front panel port is enslaved to the bridge (this holds
for both bridges used here), the bridge MAC address does not have the same
prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all
the RIFs have to have the same 38-bit MAC address prefix. Since the bridge
does not obey this limitation, the RIF cannot be created, and the
enslavement attempt is vetoed on the grounds of the configuration not being
offloadable.

The selftest itself however checks traffic prioritization and scheduling,
and the bridges serve for their L2 forwarding capabilities, and do not need
to participate in routing traffic. The IP addresses or the RIFs are
irrelevant.

Fix by disabling automatic IPv6 address generation for the HW-offloaded
bridges in this selftest, thus exempting them from mlxsw router attention.

Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In a future patch, mlxsw will start adding RIFs to uppers of front panel
port netdevices, if they have an IP address.

At the time that the front panel port is enslaved to the bridge (this holds
for both bridges used here), the bridge MAC address does not have the same
prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all
the RIFs have to have the same 38-bit MAC address prefix. Since the bridge
does not obey this limitation, the RIF cannot be created, and the
enslavement attempt is vetoed on the grounds of the configuration not being
offloadable.

The selftest itself however checks traffic prioritization and scheduling,
and the bridges serve for their L2 forwarding capabilities, and do not need
to participate in routing traffic. The IP addresses or the RIFs are
irrelevant.

Fix by disabling automatic IPv6 address generation for the HW-offloaded
bridges in this selftest, thus exempting them from mlxsw router attention.

Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>selftests: mlxsw: qos_dscp_bridge: Disable IPv6 autogen on a bridge</title>
<updated>2023-06-21T21:02:52+00:00</updated>
<author>
<name>Petr Machata</name>
<email>petrm@nvidia.com</email>
</author>
<published>2023-06-20T13:55:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6349f9bbbfb2bda12c0a633965d03435d18d930f'/>
<id>6349f9bbbfb2bda12c0a633965d03435d18d930f</id>
<content type='text'>
In a future patch, mlxsw will start adding RIFs to uppers of front panel
port netdevices, if they have an IP address.

At the time that the front panel port is enslaved to the bridge, the bridge
MAC address does not have the same prefix as other interfaces in the
system. On Nvidia Spectrum-1 machines all the RIFs have to have the same
38-bit MAC address prefix. Since the bridge does not obey this limitation,
the RIF cannot be created, and the enslavement attempt is vetoed on the
grounds of the configuration not being offloadable.

The selftest itself however checks DCB DSCP-based prioritization, and the
bridge serves for its L2 forwarding capabilities, and does not need to
participate in routing traffic. The IP address or the RIF are irrelevant.

Fix by disabling automatic IPv6 address generation for the HW-offloaded
bridge in this selftest, thus exempting it from mlxsw router attention.

Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In a future patch, mlxsw will start adding RIFs to uppers of front panel
port netdevices, if they have an IP address.

At the time that the front panel port is enslaved to the bridge, the bridge
MAC address does not have the same prefix as other interfaces in the
system. On Nvidia Spectrum-1 machines all the RIFs have to have the same
38-bit MAC address prefix. Since the bridge does not obey this limitation,
the RIF cannot be created, and the enslavement attempt is vetoed on the
grounds of the configuration not being offloadable.

The selftest itself however checks DCB DSCP-based prioritization, and the
bridge serves for its L2 forwarding capabilities, and does not need to
participate in routing traffic. The IP address or the RIF are irrelevant.

Fix by disabling automatic IPv6 address generation for the HW-offloaded
bridge in this selftest, thus exempting it from mlxsw router attention.

Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Reviewed-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
