On Thu, Mar 4, 2021 at 2:08 PM Edwin Peer wrote:
> On Thu, Mar 4, 2021 at 1:13 AM Danielle Ratson wrote:
>
> > --- a/include/linux/ethtool.h
> > +++ b/include/linux/ethtool.h
> > @@ -130,6 +130,7 @@ struct ethtool_link_ksettings {
> > } link_mo
n't claim to supply link_mode.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
possible false alarms. This is because
netif_tx_lock() only sets the frozen bit without maintaining the locks
on the individual queues.
Fixes: c3f26a269c24 ("netdev: Fix lockdep warnings in multiqueue
configurations.")
Signed-off-by: Edwin Peer
---
include/linux/netdevice.h | 2 ++
1 fi
ethtool: Expose the number of lanes in use
> mlxsw: ethtool: Remove max lanes filtering
> mlxsw: ethtool: Add support for setting lanes when autoneg is off
> mlxsw: ethtool: Pass link mode in use to ethtool
> net: selftests: Add lanes setting test
Reviewed by: Edwin Peer
Rega
conversation when it comes to FEC. There simply is no way for upstream
> developers to review the behavior is correct.
Given that supported is only defined in the context of autoneg today,
once could still specify. But again, you raise a fair concern.
The asymmetry in interface is still ugly though, you get to decide
which ugly is worse. :P
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
SR because CR is physically plugged in.
That way, the user knows what options are legal and the kernel knows
what it can reject.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
mbinations based on the supported bitmask before
calling upon the driver to select it.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
on link mode,
the latter is no worse than what we have today.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
corresponding to media
that's not plugged in wouldn't be listed in the supported set, so
there's no reason the user should expect to be able to set those.
There's no ambiguity or information loss if you refuse to set modes
that don't have the matching media attached.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
On Tue, Jan 26, 2021 at 12:36 PM Jakub Kicinski wrote:
> > Fixes: 3b766cd83232 ("net/core: Add reading VF statistics through the PF
> > netdevice")
> > Fixes: c5a9f6f0ab40 ("net/core: Add drop counters to VF statistics")
> > Signed-off-by: Edwin Peer
On Mon, Jan 25, 2021 at 5:56 PM Jakub Kicinski wrote:
> > Fixes: 3b766cd83232 ("net/core: Add reading VF statistics through the PF
> > netdevice")
> > Fixes: c5a9f6f0ab40 ("net/core: Add drop counters to VF statistics")
> > Signed-off-by: Edwin Peer
require further discussion.
[1]
https://lore.kernel.org/netdev/20210115225950.18762-1-edwin.p...@broadcom.com/
[2] https://marc.info/?l=linux-netdev&m=161163943811663 (missing on lore)
Edwin Peer (1):
rtnetlink: extend RTEXT_FILTER_SKIP_STATS to IFLA_VF_INFO
net/co
Don't request statistics we do not intend to render. This avoids the
possibility of a truncated IFLA_VFINFO_LIST when statistics are not
requested as well as the fetching of unnecessary data.
Signed-off-by: Edwin Peer
---
ip/ipaddress.c | 6 +-
ip/iplink.c| 3 +++
2 files chang
ttps://marc.info/?l=linux-netdev&m=161163943811663
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
The kernel might truncate VF info in IFLA_VFINFO_LIST. Compare the
expected number of VFs in IFLA_NUM_VF to how many were found in the
list and warn accordingly.
Signed-off-by: Edwin Peer
---
ip/ipaddress.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/ip
tion for the maximum number of VFs
supported by PCI.
Fixes: 3b766cd83232 ("net/core: Add reading VF statistics through the PF
netdevice")
Fixes: c5a9f6f0ab40 ("net/core: Add drop counters to VF statistics")
Signed-off-by: Edwin Peer
---
net/core/rtnetlink.c | 96
o. But, this asymmetry
aside, if link_mode may eventually become R/W at the driver API, as
you suggest, then it is more appropriate to guard it with a capability
bit, as has been done for lanes, rather than use the -1 special value
to indicate that the driver did not set it.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
rds a newer API,
by insisting that the development of new functionality happens there,
and actively making sure the old API sucks to use.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
> space.
If the above is true, is there really a need to scale up CAM?
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
On Mon, Jan 25, 2021 at 10:35 AM Edwin Peer wrote:
> > Several weeks back, Jason already answered this VF scaling question from
> > you at discussion [1].
> >
> > [1] https://lore.kernel.org/netdev/20201216023928.gg552...@nvidia.com/
Regarding these costs:
> A lo
revious discussion, so we'll need to reinvent it again later).
Adds to confusion.
It's not easier for vendors either. Now we need to get users onto new
drivers to exploit it, with all the distribution lags that entails
(where existing drivers would work for SR-IOV). Some vendors will
support it, some won't, further adding to user confusion.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
x27;s double the cost? I don't know that it is, but does that
warrant the additional complexity of SFs? We should try to quantify.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
t; Can Linux even assign more bus numbers to a port without firmware
> help? Bus numbers are something that requires the root complex to be
> aware of to setup routability.
I'm not sure, presumably something already infers this for the first
additional bus number based on the SR-IOV config
cost argument at the
time because the core answer was "They can't", however, the fact is,
PCI can.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
at's not the same thing. If it were, you wouldn't need the lanes
parameter in the first place.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
captured Bus Number plus any
additional Bus Numbers configured by
software. See Section 9.2.1.2 for details.
- Use of multiple Bus Numbers enables a device to support a very large
number of VFs - up to the size
of the Routing ID space minus the bits used to identify intervening busses"
Re
On Sat, Jan 23, 2021 at 12:42 PM Edwin Peer wrote:
> Then, if nla_put() can detect nesting errors, there's the issue of
> what to do in the case of errors. Case in point, the IFLA_VFINFO_LIST
> scenario would now require explicit error handling in the generator
> logic, beca
rokenness that is
guaranteed to not make things worse, but we can't know where we need
to do that apriori and would need to explicitly handle each case as
they come up.
Hard errors on nest overflow can only reliably work for new code. That
is, assuming it is tested to the extremes when it goes i
truncated by the kernel's nla_nest_end().
A recent ABI fix moves the VF stats into an independent list when
requested, thus avoiding the problem. Send requests using the new
RTEXT_FILTER_VF_SEPARATE_STATS filter and render the stats from
the alternate list instead.
Signed-off-by: Edwin Peer
--
Don't request statistics we do not intend to render. This is a step
towards avoiding a truncated IFLA_VFINFO_LIST. It also avoids fetching
unnecessary data, reducing netlink traffic.
Signed-off-by: Edwin Peer
---
ip/ipaddress.c | 6 +-
ip/iplink.c| 3 +++
2 files changed, 8 inser
This primarily pulls in the ABI changes needed to detect truncated
lists of netlink attributes as well as the bits necessary to elevate
IFLA_VF_INFO stats out of IFLA_VFINFO_LIST. Unrelated changes in the
affected files were also synced.
Signed-off-by: Edwin Peer
---
include/uapi/linux
many were found in the list and warn accordingly.
Signed-off-by: Edwin Peer
---
ip/ipaddress.c | 9 -
lib/libnetlink.c | 12
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 571346b15cc3..0bbcee2b3bb2 100644
--- a/ip
ot;)
Fixes: c5a9f6f0ab40 ("net/core: Add drop counters to VF statistics")
Signed-off-by: Edwin Peer
---
include/uapi/linux/if_link.h | 1 +
include/uapi/linux/rtnetlink.h | 1 +
net/core/rtnetlink.c | 24 +---
3 files changed, 23 insertions(+), 3 deletions(-)
Moving VF stats into their own function will facilitate separating
them out later.
No functional change.
Signed-off-by: Edwin Peer
---
net/core/rtnetlink.c | 66 +---
1 file changed, 38 insertions(+), 28 deletions(-)
diff --git a/net/core/rtnetlink.c b
IFLA_NUM_VF to determine how many VFs were expected.
Fixes: bfa83a9e03cf ("[NETLINK]: Type-safe netlink messages/attributes
interface")
Signed-off-by: Edwin Peer
---
include/net/netlink.h| 11 +--
include/uapi/linux/netlink.h | 1 +
lib/nlattr.c
tion for the maximum number of VFs
supported by PCI.
Fixes: 3b766cd83232 ("net/core: Add reading VF statistics through the PF
netdevice")
Fixes: c5a9f6f0ab40 ("net/core: Add drop counters to VF statistics")
Signed-off-by: Edwin Peer
---
net/core/rtnetlink.c | 96
s followed by an iproute2 series to take
advantage of the changes.
[1]
https://lore.kernel.org/netdev/20210115225950.18762-1-edwin.p...@broadcom.com/
Edwin Peer (4):
netlink: truncate overlength attribute list in nla_nest_end()
rtnetlink: extend RTEXT_FILTER_SKIP_STATS to IFLA_VF_INFO
user space to set
link mode directly too (in addition to being able to constrain lanes
for autoneg or forced speeds)?
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
.speed = SPEED_ ## _speed, \
.lanes = __LINK_MODE_LANES ## _type, \
instead of specifying lanes for each link mode defined below?
Regards,
Edwin Peer
> static const struct link_mode_info link_mode_params[] = {
> - __DEFINE_L
red_many()
>
> net/core/dev.c | 210 +++--
> 1 file changed, 98 insertions(+), 112 deletions(-)
Reviewed-by: Edwin Peer
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
of said state into normal open/up. Of
course, the tools would need to be updated to know about such a new
event too. EAGAIN does seem simpler. In our case, we don't expect to
be polling too long, or frequently for that matter. It is
exceptionally rare that the firmware wouldn't be ready, but
On Mon, Jan 18, 2021 at 2:57 PM David Ahern wrote:
> On 1/18/21 11:01 AM, Edwin Peer wrote:
> > I'm facing a similar issue with NIC firmware that isn't yet ready by
> > device open time, but have been resisting the urge to lie to the stack
>
> why not have the nd
works today. Even though the VF list is bust,
the rest of the netdevs are still dumped correctly. A hard fail would
break those too.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
ioned way to
communicate the failure. Aren't the issues here similar?
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
warning will identify places that need to be fixed.
Assuming we fix nla_nest_end() and error in some way, how does that
assist iproute2?
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
e user isn't going to care about this technicality. If the kernel
errors out here, then the user sees zero VFs when adding one more VF.
That's still a bug, even though the malformed message is fixed. An API
bug is still a bug, except we seemingly can't fix it because it'
O_LIST exceeds 65535 bytes can
> provide devlink interface to handle them.
Does that imply reworking ip link to use devlink interfaces as the fix?
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
fferent and valid output that imparts
equivalent information. I do hear the concern though.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
esign. Such ideas are all moot, however, because
VF config has been punted to switchdev and any new work should happen
there instead.
Signed-off-by: Edwin Peer
---
ip/ipaddress.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/ip/ipaddress.c b/ip/
s). Better still would be to define the UAPI in terms of
the absolute link mode enum index (with the modes that are not
compatible with the presently installed media type being rejected).
Regards,
Edwin Peer
On Wed, Jan 6, 2021 at 5:08 AM Danielle Ratson wrote:
>
> From: Danielle Ratson
>
&
ns regarding SR-IOV VFs when we have vendor
specific aux bus drivers talking directly to vendor specific backend
hardware resources. In this regard, don't subfunctions, by definition,
have most of the same limitations as SR-IOV VFs?
Regards,
Edwin Peer
--
This electronic communication and t
ser doesn't necessarily want
to specify physical media in these cases, something that is implied
by the full link mode definition.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
the same strings, but not much more. And then,
it's probably better to give each dimension their own field in a struct and be
done, lest we run out of bits. Let the user space tool map the link mode
string onto the appropriate struct values.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
encoding can be implied by the
speed if the number of lanes is a property of the port configuration. In which
case the existing ethtool interface is sufficient.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
ther than unused lanes he can't use, because they would be
attached to a port using an encoding that doesn't need them. If he wasn't
planning on using the additional port, he loses nothing. Otherwise, he gains
something he would not otherwise have had (it's win-win). From the
x27;t
sufficient device MAC resources, stats contexts, whatever), then that's
a different story. But, even so, perhaps the port lane topology more
appropriately belongs as part of a device configuration interface in
devlink and the number of lanes available to a port should be a
property of the port instead of a link mode knob?
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
me than leaving lanes unused and always wasted.
Otherwise, the earlier suggestion of fully specifying the forced link
mode (although I don't think Andrew articulated it quite that way)
instead of a forced speed and separate lane mode makes most
sense.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
west
signalling mode that utilizes all the available lanes.
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
rkqueue("bnxt_pf_wq");
> if (!bnxt_pf_wq) {
> dev_err(&pdev->dev, "Unable to create
> workqueue.\n");
> + rc = -ENOMEM;
> goto init_err_pci_clean;
>
amp;
> dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)) != 0) {
> dev_err(&pdev->dev, "System does not support DMA,
> aborting\n");
> + rc = -EIO;
> goto init_err_disable;
> }
>
> --
> 2.9.5
Reviewed-by: Edwin Peer
Regards,
Edwin Peer
smime.p7s
Description: S/MIME Cryptographic Signature
IEEE 30.3.1.1.21 aMulticastFramesReceivedOK" here and provide an
appropriate citation reference at the end, or perhaps a link.
Regards,
Edwin Peer
;s, perhaps we could set those messages to silent if
> it's a VF PCI ID? Or handle this in bnxt_hwmon_open() if it's a VF PCI
> ID (eg, not do anything)?
I expect not exposing the temperature to VFs is by design. Thanks for
bringing this to attention, I'll look into it.
Regards,
Edwin Peer
uce MTU, because
PMTU is something more dynamic. I guess I kind of half thought about
this for gre6, where this is what I did because PMTU is so much more
in your face for IPv6.
Regards,
Edwin Peer
It's not clear how useful VLANs layered over Ethernet emulated over NTB
transport are, but they are presently allowed. The L2 emulation exposed
by NTB does not account for possible VLAN tags in the space allocated
for Ethernet headers when configured for maximal MTU.
Signed-off-by: Edwin
ly to disable
support for VLANs. Similarly the SB1000 is RX only.
VLANs don't make sense for VRF devices because they are raw IP. Relying
on NETIF_F_VLAN_CHALLENGED is unnecessary if the device type is set
appropriately.
Signed-off-by: Edwin Peer
---
drivers/infiniband/ulp/ipoib/ipoib_ma
erhaps this
could be revised too. That would leave only ipvlan, which unfortantely
does not lend itself to removing NET_F_VLAN_CHALLENGED entirely, since
it has a mode exposing an L2 Ethernet device for which VLANs do not
have any sensible meaning.
Signed-off-by: Edwin Peer
---
Documentati
VLANs layered above aggregate devices such as bonds and teams should
inherit the MTU limitations of the devices underlying the aggregate.
If any one of the slave devices is constrained by IFF_NO_VLAN_ROOM,
then so must the aggregate as a whole.
Signed-off-by: Edwin Peer
---
drivers/net/bonding
need to be constrained, because non-VLAN packets will share the
same path MTU.
Signed-off-by: Edwin Peer
---
net/ipv4/ip_tunnel.c | 2 ++
net/ipv6/ip6_gre.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index f4f1d11eab50
unneled in L3, hence restricting VLANs to
ARPHRD_ETHER devices. Between ARPHRD_ETHER and IFF_NO_VLAN_ROOM, it now
seemed only a hop and a skip to eliminate NET_F_VLAN_CHALLENGED too, but
alas there are still a few holdouts that would appear to require more of
a moonshot to address.
Edwin Peer (
Support offloads for nested VLANs in the same fashion as is done for
VXLAN interfaces. In particular, this allows software GSO and checksum
offload to function when VLANs are encapsulated inside Geneve tunnels.
Signed-off-by: Edwin Peer
---
drivers/net/geneve.c | 2 ++
1 file changed, 2
will always be adjusted to accommodate the VLAN tag.
Signed-off-by: Edwin Peer
---
drivers/net/vxlan.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index a0015cdedfaf..3e9c65eb4737 100644
--- a/drivers/net/vxlan.c
+++ b
smaller MTU
value than the maximum it supports, then there is sufficient room and
IFF_NO_VLAN_ROOM should not be set.
Signed-off-by: Edwin Peer
---
drivers/net/macsec.c | 6 --
include/linux/if_vlan.h | 40 +++
include/linux/netdevice.h | 6
can be safely removed restoring the correct VLAN behavior.
Fixes: 0287587884b15 ("net: better IFF_XMIT_DST_RELEASE support")
Signed-off-by: Edwin Peer
---
drivers/net/bonding/bond_main.c | 12
drivers/net/net_failover.c | 16
drivers/net/team/team
always be adjusted to accommodate the VLAN tag.
Signed-off-by: Edwin Peer
---
drivers/net/geneve.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 8d790cf85b21..9c8e6f242f77 100644
--- a/drivers/net/geneve.c
the L2TP device's MTU is changed. This function
needed to move before the net_device_ops definition in order to avoid a
forward declaration, but instead the definition of net_device_ops is
moved so that the refactoring changes are better represented in the
diff.
Signed-off-by: Edwin Peer
---
anism to trigger the actual reset here.
This is a parameter to enable or disable the hot reset functionality.
It's configuration, not an action.
Regards,
Edwin Peer
On Tue, May 5, 2020 at 11:46 PM Bartosz Golaszewski wrote:
> Re the last bit in priv_flags: is this really a problem though? It's
> not like struct net_device must remain stable - e.g. we can make
> priv_flags a bitmap.
Fair enough.
Regards,
Edwin Peer
On Tue, May 5, 2020 at 12:57 PM Julian Wiedmann wrote:
> It's a virtual device, _none_ of them make much sense?!
Why not introduce a new reset bit that captures the semantics of
whatever qeth_schedule_recovery does?
Regards,
Edwin Peer
; +
> + return 0;
> +}
> +EXPORT_SYMBOL(devm_register_netdev);
> +
> int netdev_refcnt_read(const struct net_device *dev)
> {
> int i, refcnt = 0;
> diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
> index c8b903302ff2..ce9b5e576f20 100644
> --- a/net/ethernet/eth.c
> +++ b/net/ethernet/eth.c
> @@ -423,6 +423,7 @@ struct net_device *devm_alloc_etherdev_mqs(struct device
> *dev, int sizeof_priv,
>
> *dr = netdev;
> devres_add(dev, dr);
> + netdev->priv_flags |= IFF_IS_DEVRES;
>
> return netdev;
> }
> --
> 2.25.0
>
Regards,
Edwin Peer
79 matches
Mail list logo
