Displaying 20 results from an estimated 26 matches for "nla_get_u32".
2016 Jun 30
2
[PATCH net-next V3 5/6] net: introduce NETDEV_CHANGE_TX_QUEUE_LEN
...t timing I was just looking into this because I need it for the
qdisc side.
It looks like this covers the sysfs change but the tx_queue_len can
also be changed via rtnetlink as well. So we need another patch for
that path right?
if (tb[IFLA_TXQLEN]) {
unsigned long value = nla_get_u32(tb[IFLA_TXQLEN]);
if (dev->tx_queue_len ^ value)
status |= DO_SETLINK_NOTIFY;
dev->tx_queue_len = value;
}
Thanks,
John
2016 Jun 30
2
[PATCH net-next V3 5/6] net: introduce NETDEV_CHANGE_TX_QUEUE_LEN
...t timing I was just looking into this because I need it for the
qdisc side.
It looks like this covers the sysfs change but the tx_queue_len can
also be changed via rtnetlink as well. So we need another patch for
that path right?
if (tb[IFLA_TXQLEN]) {
unsigned long value = nla_get_u32(tb[IFLA_TXQLEN]);
if (dev->tx_queue_len ^ value)
status |= DO_SETLINK_NOTIFY;
dev->tx_queue_len = value;
}
Thanks,
John
2016 Jun 30
1
[PATCH net-next V3 5/6] net: introduce NETDEV_CHANGE_TX_QUEUE_LEN
...qdisc side.
>>
>> It looks like this covers the sysfs change but the tx_queue_len can
>> also be changed via rtnetlink as well. So we need another patch for
>> that path right?
>>
>> if (tb[IFLA_TXQLEN]) {
>> unsigned long value = nla_get_u32(tb[IFLA_TXQLEN]);
>>
>> if (dev->tx_queue_len ^ value)
>> status |= DO_SETLINK_NOTIFY;
>>
>> dev->tx_queue_len = value;
>> }
>>
>> Thanks,
>> John
>>
>
> Right...
2016 Jun 30
1
[PATCH net-next V3 5/6] net: introduce NETDEV_CHANGE_TX_QUEUE_LEN
...qdisc side.
>>
>> It looks like this covers the sysfs change but the tx_queue_len can
>> also be changed via rtnetlink as well. So we need another patch for
>> that path right?
>>
>> if (tb[IFLA_TXQLEN]) {
>> unsigned long value = nla_get_u32(tb[IFLA_TXQLEN]);
>>
>> if (dev->tx_queue_len ^ value)
>> status |= DO_SETLINK_NOTIFY;
>>
>> dev->tx_queue_len = value;
>> }
>>
>> Thanks,
>> John
>>
>
> Right...
2009 Nov 24
4
[Bridge] [PATCHv2 0/4] macvlan: add vepa and bridge mode
Second version, all feedback so far addressed, thanks for the
help and interest!
The patch to iproute2 has not changed, so I'm not including
it this time. Patch 4/4 (the netlink interface) is basically
unchanged as well but included for completeness.
The other changes have moved forward a bit, to the point where
I find them a lot cleaner and am more confident in the code
being ready for
2009 Nov 24
4
[Bridge] [PATCHv2 0/4] macvlan: add vepa and bridge mode
Second version, all feedback so far addressed, thanks for the
help and interest!
The patch to iproute2 has not changed, so I'm not including
it this time. Patch 4/4 (the netlink interface) is basically
unchanged as well but included for completeness.
The other changes have moved forward a bit, to the point where
I find them a lot cleaner and am more confident in the code
being ready for
2009 Nov 24
4
[Bridge] [PATCHv2 0/4] macvlan: add vepa and bridge mode
Second version, all feedback so far addressed, thanks for the
help and interest!
The patch to iproute2 has not changed, so I'm not including
it this time. Patch 4/4 (the netlink interface) is basically
unchanged as well but included for completeness.
The other changes have moved forward a bit, to the point where
I find them a lot cleaner and am more confident in the code
being ready for
2009 Nov 26
5
[Bridge] [PATCHv3 0/4] macvlan: add vepa and bridge mode
Not many changes this time, just integrated a bug fix
and all the coding style feedback from Eric Dumazet
and Patrick McHardy.
I'll keep the patch for network namespaces on the tx
path out of this series for now, because the discussion
is still ongoing and it addresses an unrelated issue.
---
Version 2 description:
The patch to iproute2 has not changed, so I'm not including
it this
2009 Nov 26
5
[Bridge] [PATCHv3 0/4] macvlan: add vepa and bridge mode
Not many changes this time, just integrated a bug fix
and all the coding style feedback from Eric Dumazet
and Patrick McHardy.
I'll keep the patch for network namespaces on the tx
path out of this series for now, because the discussion
is still ongoing and it addresses an unrelated issue.
---
Version 2 description:
The patch to iproute2 has not changed, so I'm not including
it this
2009 Nov 26
5
[Bridge] [PATCHv3 0/4] macvlan: add vepa and bridge mode
Not many changes this time, just integrated a bug fix
and all the coding style feedback from Eric Dumazet
and Patrick McHardy.
I'll keep the patch for network namespaces on the tx
path out of this series for now, because the discussion
is still ongoing and it addresses an unrelated issue.
---
Version 2 description:
The patch to iproute2 has not changed, so I'm not including
it this
2016 Jun 30
0
[PATCH net-next V3 5/6] net: introduce NETDEV_CHANGE_TX_QUEUE_LEN
...cause I need it for the
> qdisc side.
>
> It looks like this covers the sysfs change but the tx_queue_len can
> also be changed via rtnetlink as well. So we need another patch for
> that path right?
>
> if (tb[IFLA_TXQLEN]) {
> unsigned long value = nla_get_u32(tb[IFLA_TXQLEN]);
>
> if (dev->tx_queue_len ^ value)
> status |= DO_SETLINK_NOTIFY;
>
> dev->tx_queue_len = value;
> }
>
> Thanks,
> John
>
Right, will do this in next version.
Thanks
2016 Jun 30
0
[PATCH net-next V4 5/6] net: introduce NETDEV_CHANGE_TX_QUEUE_LEN
...AULT;
+ }
+ }
+
return 0;
}
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index eb49ca2..b16b779 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1927,11 +1927,19 @@ static int do_setlink(const struct sk_buff *skb,
if (tb[IFLA_TXQLEN]) {
unsigned long value = nla_get_u32(tb[IFLA_TXQLEN]);
-
- if (dev->tx_queue_len ^ value)
+ unsigned long orig_len = dev->tx_queue_len;
+
+ if (dev->tx_queue_len ^ value) {
+ dev->tx_queue_len = value;
+ err = call_netdevice_notifiers(
+ NETDEV_CHANGE_TX_QUEUE_LEN, dev);
+ err = notifier_to_errno(err);
+...
2013 Apr 30
6
[Bridge] [PATCHv4 net-next 0/2] Add two new flags to bridge.
The following series adds 2 new flags to bridge. One flag allows
the user to control whether mac learning is performed on the interface
or not. By default mac learning is on.
The other flag allows the user to control whether unicast traffic
is flooded (send without an fdb) to a given unicast port. Default is
on.
Changes since v4:
- Implemented Stephen's suggestions.
Changes since v2:
-
2023 May 15
5
[Bridge] [PATCH net-next 1/2] bridge: Add a limit on FDB entries
...nk.c b/net/bridge/br_netlink.c
index 05c5863d2e20..e5b8d36a3291 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -1527,6 +1527,12 @@ static int br_changelink(struct net_device *brdev, struct nlattr *tb[],
return err;
}
+ if (data[IFLA_BR_FDB_MAX_ENTRIES]) {
+ u32 val = nla_get_u32(data[IFLA_BR_FDB_MAX_ENTRIES]);
+
+ br->fdb_max_entries = val;
+ }
+
return 0;
}
@@ -1656,7 +1662,8 @@ static int br_fill_info(struct sk_buff *skb, const struct net_device *brdev)
nla_put_u8(skb, IFLA_BR_TOPOLOGY_CHANGE_DETECTED,
br->topology_change_detected) ||
nl...
2023 May 15
3
[Bridge] [PATCH net-next 1/2] bridge: Add a limit on FDB entries
...5863d2e20..e5b8d36a3291 100644
> --- a/net/bridge/br_netlink.c
> +++ b/net/bridge/br_netlink.c
> @@ -1527,6 +1527,12 @@ static int br_changelink(struct net_device *brdev, struct nlattr *tb[],
> return err;
> }
>
> + if (data[IFLA_BR_FDB_MAX_ENTRIES]) {
> + u32 val = nla_get_u32(data[IFLA_BR_FDB_MAX_ENTRIES]);
> +
> + br->fdb_max_entries = val;
> + }
> +
> return 0;
> }
>
> @@ -1656,7 +1662,8 @@ static int br_fill_info(struct sk_buff *skb, const struct net_device *brdev)
> nla_put_u8(skb, IFLA_BR_TOPOLOGY_CHANGE_DETECTED,
>...
2023 Jun 19
2
[Bridge] [PATCH net-next v2 2/3] bridge: Add a limit on learned FDB entries
...et/bridge/br_netlink.c
index 05c5863d2e20..954c468d52ec 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -1527,6 +1527,12 @@ static int br_changelink(struct net_device *brdev, struct nlattr *tb[],
return err;
}
+ if (data[IFLA_BR_FDB_MAX_LEARNED_ENTRIES]) {
+ u32 val = nla_get_u32(data[IFLA_BR_FDB_MAX_LEARNED_ENTRIES]);
+
+ br->fdb_max_learned_entries = val;
+ }
+
return 0;
}
@@ -1581,6 +1587,8 @@ static size_t br_get_size(const struct net_device *brdev)
nla_total_size_64bit(sizeof(u64)) + /* IFLA_BR_TOPOLOGY_CHANGE_TIMER */
nla_total_size_64bit(si...
2009 Nov 17
11
[Bridge] [PATCH 0/3] macvlan: add vepa and bridge mode
This is based on an earlier patch from Eric Biederman adding
forwarding between macvlans. I extended his approach to
allow the administrator to choose the mode for each macvlan,
and to implement a functional VEPA between macvlan.
Still missing from this is support for communication between
the lower device that the macvlans are based on. This would
be extremely useful but as others have found out
2009 Nov 17
11
[Bridge] [PATCH 0/3] macvlan: add vepa and bridge mode
This is based on an earlier patch from Eric Biederman adding
forwarding between macvlans. I extended his approach to
allow the administrator to choose the mode for each macvlan,
and to implement a functional VEPA between macvlan.
Still missing from this is support for communication between
the lower device that the macvlans are based on. This would
be extremely useful but as others have found out
2009 Nov 17
11
[Bridge] [PATCH 0/3] macvlan: add vepa and bridge mode
This is based on an earlier patch from Eric Biederman adding
forwarding between macvlans. I extended his approach to
allow the administrator to choose the mode for each macvlan,
and to implement a functional VEPA between macvlan.
Still missing from this is support for communication between
the lower device that the macvlans are based on. This would
be extremely useful but as others have found out
2023 Jun 19
4
[Bridge] [PATCH net-next v2 0/3, iproute2-next 0/1] bridge: Add a limit on learned FDB entries
Introduce a limit on the amount of learned FDB entries on a bridge,
configured by netlink with a build time default on bridge creation in
the kernel config.
For backwards compatibility the kernel config default is disabling the
limit (0).
Without any limit a malicious actor may OOM a kernel by spamming packets
with changing MAC addresses on their bridge port, so allow the bridge
creator to limit