* Re: Is this 32-bit NCM?
From: Kevin Zhu @ 2014-11-28 9:23 UTC (permalink / raw)
To: Enrico Mioso
Cc: Alex Strizhevsky, Bjørn Mork, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Eli Britstein
In-Reply-To: <alpine.LNX.2.03.1411281014450.4101@gmail.com>
Yes. The MACs are right. When I started Wireshark, promisc mode was set.
Regards,
Kevin
On 11/28/2014 05:17 PM, Enrico Mioso wrote:
> Sorry - resending message to all.
> Is the MAC right? In my case it was, but ... you never know.
> And - have you tried the promisc mode, just in case... don't know if this might
> even be implementedi n the driver, think not, but...
> I don't know what to think anymore.
> this ARP packet seems the same as with windows... but might be it's only my
> impression.
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Kevin Zhu @ 2014-11-28 9:25 UTC (permalink / raw)
To: Enrico Mioso
Cc: Alex Strizhevsky, Bjørn Mork, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Eli Britstein
In-Reply-To: <alpine.LNX.2.03.1411281014450.4101@gmail.com>
The only difference I can tell now is windows does not pack the NDP with
zeros, it just sends whatever the skb buffer has, except the alignment.
Regards,
Kevin
On 11/28/2014 05:17 PM, Enrico Mioso wrote:
> Sorry - resending message to all.
> Is the MAC right? In my case it was, but ... you never know.
> And - have you tried the promisc mode, just in case... don't know if this might
> even be implementedi n the driver, think not, but...
> I don't know what to think anymore.
> this ARP packet seems the same as with windows... but might be it's only my
> impression.
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Bjørn Mork @ 2014-11-28 9:29 UTC (permalink / raw)
To: Enrico Mioso
Cc: Alex Strizhevsky, ShaojunMidge.Tan, Mingying.Zhu, youtux,
linux-usb, netdev, Eli.Britstein
In-Reply-To: <alpine.LNX.2.03.1411271932510.1548@gmail.com>
Enrico Mioso <mrkiko.rs@gmail.com> writes:
> What I suspect, is that all this mess started when Huawei introduce new
> firmware releases that changed something in the IPV6 support.
> Bjorn - do you remember when a guy called Thomas reported us a problem about an
> LTE huawei modem that wasn't working with huawei_cdc_ncm?
> And you then discovered the problem was originated from some changes in the
> ordering of cdc_ncm actions; what happened then?
> Did Thomas get his modem back to working state?
yes, that bug was fixed by
commit ff0992e9036e9810e7cd45234fa32ca1e79750e2
Author: Bjørn Mork <bjorn@mork.no>
Date: Mon Mar 17 16:25:18 2014 +0100
net: cdc_ncm: fix control message ordering
This is a context modified revert of commit 6a9612e2cb22
("net: cdc_ncm: remove ncm_parm field") which introduced
a NCM specification violation, causing setup errors for
some devices. These errors resulted in the device and
host disagreeing about shared settings, with complete
failure to communicate as the end result.
The NCM specification require that many of the NCM specific
control reuests are sent only while the NCM Data Interface
is in alternate setting 0. Reverting the commit ensures that
we follow this requirement.
Fixes: 6a9612e2cb22 ("net: cdc_ncm: remove ncm_parm field")
Reported-and-tested-by: Pasi Kärkkäinen <pasik@iki.fi>
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Bjørn
^ permalink raw reply
* Re: [PATCH net] bpf: x86: fix epilogue generation for eBPF programs
From: Daniel Borkmann @ 2014-11-28 9:39 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Zi Shen Lim, Eric Dumazet, H. Peter Anvin,
Thomas Gleixner, Ingo Molnar, Network Development, LKML
In-Reply-To: <CAMEtUuyzDs2Nz8WHdEZXmY9JOZx=w2UwUF06Kq5qcgkaaRKs3A@mail.gmail.com>
On 11/28/2014 06:55 AM, Alexei Starovoitov wrote:
> On Thu, Nov 27, 2014 at 1:52 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
>> On 11/27/2014 06:02 AM, Alexei Starovoitov wrote:
>>>
>>> classic BPF has a restriction that last insn is always BPF_RET.
>>> eBPF doesn't have BPF_RET instruction and this restriction.
>>> It has BPF_EXIT insn which can appear anywhere in the program
>>> one or more times and it doesn't have to be last insn.
>>> Fix eBPF JIT to emit epilogue when first BPF_EXIT is seen
>>> and all other BPF_EXIT instructions will be emitted as jump.
>>>
>>> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
>>> ---
>>> Note, this bug is applicable only to native eBPF programs
>>> which first were introduced in 3.18, so no need to send it
>>> to stable and therefore no 'Fixes' tag.
>>
>> Btw, even if it's not sent to -stable, a 'Fixes:' tag is useful
>> information for backporting and regression tracking, preferably
>> always mentioned where it can clearly be identified.
>
> Well I didn't mention it, as I said, because I don't think it
> needs backporting. Otherwise with the tag the tools might
> pick it up automatically? Just a guess.
No, Dave selects -stable material on a case-by-case basis and bundles
it up eventually; after -net was merged, it's then pushed to -stable
by himself (see Documentation/networking/netdev-FAQ.txt +114). So the
comment below "---" is absolutely okay.
It can well be, that some people/companies cannot switch for various
reasons immediately to the next kernels, but nevertheless would like
to have a certain features included, so generally regression tracking
via 'Fixes:' tag is extremely useful/valuable. ;)
> Fixes: 622582786c9e ("net: filter: x86: internal BPF JIT")
...
>> Why this type change here? This seems a bit out of context (I would
>> have expected a mention of this in the commit message, otherwise).
>
> The reason for signed is the following:
> jmp offset to epilogue is computed as:
> jmp_offset = ctx->cleanup_addr - addrs[i]
> when cleanup_addr was always last insn it wasn't a problem,
> since result of subtraction was positive.
> Now, since epilogue will be in the middle of JITed
> code the jmps to epilogue may be negative
Ok, thanks for the clarification, Alexei.
^ permalink raw reply
* Re: [patch net-next v3 08/17] bridge: call netdev_sw_port_stp_update when bridge port STP status changes
From: Roopa Prabhu @ 2014-11-28 10:05 UTC (permalink / raw)
To: Scott Feldman
Cc: Jiri Pirko, Netdev, David S. Miller, nhorman@tuxdriver.com,
Andy Gospodarek, Thomas Graf, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Jamal Hadi Salim,
Florian Fainelli, John Linville
In-Reply-To: <CAE4R7bAiEyztdGo2BMVGXq9phfASHsMU+QW4oocTmr9=4antxw@mail.gmail.com>
On 11/25/14, 5:35 PM, Scott Feldman wrote:
> So offload is a little strong for this particular function.
I just meant the flag (or mode) that you introduced for the swdev.
(The name of that flag ... offload or not ...is still being discussed.
I tend to use the name offload because i was voting for it :).
> The
> bridge driver or external STP process (msptd) is still controlling STP
> state for the port and processing the BPDUs. When the state changes
> on the port, the bridge driver is letting HW know, that's it.
I understand that. In which case, we should not call it stp state.
It is just port state. And since it is yet another port attribute like
port priority,
we should be able to use the same api to offload it to hw just like the
other port attributes.
And, Thats why i tried to generalize all bridge port attribute set by
introducing one generic netdev_sw_port_set_attr api.
https://marc.info/?l=linux-netdev&m=141661018619712&w=2
And coming back to my original comment in this thread,
the port state should be offloaded to hw only when the swdev mode (or hw
offload mode ;) is set.
> If the
> port driver can't do anything with that notification, then it should
> not implement ndo_switch_port_stp_update. If it does implement
> ndo_switch_port_stp_update, then it can adjust its HW (e.g. disable
> port if BR_DISABLED, etc), and return err code if somehow it failed
> while adjusting HW.
>
> This is not offloading STP state ctrl plane to HW. The ctrl plane is
> kept in bridge driver (or mstpd) in SW. HW stays dumb in this model.
> The bridge currently has policy control to turn on/off STP per bridge
> and a netlink hook for external processes to change STP state.
>
> On Tue, Nov 25, 2014 at 12:48 PM, Roopa Prabhu
> <roopa@cumulusnetworks.com> wrote:
>> On 11/25/14, 2:28 AM, Jiri Pirko wrote:
>>> From: Scott Feldman <sfeldma@gmail.com>
>>>
>>> To notify switch driver of change in STP state of bridge port, add new
>>> .ndo op and provide switchdev wrapper func to call ndo op. Use it in
>>> bridge
>>> code then.
>>>
>>> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>> ---
>>> v2->v3:
>>> -changed "sw" string to "switch" to avoid confusion
>>> v1->v2:
>>> -no change
>>> ---
>>> include/linux/netdevice.h | 5 +++++
>>> include/net/switchdev.h | 7 +++++++
>>> net/bridge/br_stp.c | 2 ++
>>> net/switchdev/switchdev.c | 19 +++++++++++++++++++
>>> 4 files changed, 33 insertions(+)
>>>
>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>> index ce096dc..66cb64e 100644
>>> --- a/include/linux/netdevice.h
>>> +++ b/include/linux/netdevice.h
>>> @@ -1024,6 +1024,9 @@ typedef u16 (*select_queue_fallback_t)(struct
>>> net_device *dev,
>>> * Called to get an ID of the switch chip this port is part of.
>>> * If driver implements this, it indicates that it represents a port
>>> * of a switch chip.
>>> + * int (*ndo_switch_port_stp_update)(struct net_device *dev, u8 state);
>>> + * Called to notify switch device port of bridge port STP
>>> + * state change.
>>> */
>>> struct net_device_ops {
>>> int (*ndo_init)(struct net_device *dev);
>>> @@ -1180,6 +1183,8 @@ struct net_device_ops {
>>> #ifdef CONFIG_NET_SWITCHDEV
>>> int (*ndo_switch_parent_id_get)(struct
>>> net_device *dev,
>>> struct
>>> netdev_phys_item_id *psid);
>>> + int (*ndo_switch_port_stp_update)(struct
>>> net_device *dev,
>>> + u8 state);
>>> #endif
>>> };
>>> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
>>> index 7a52360..8a6d164 100644
>>> --- a/include/net/switchdev.h
>>> +++ b/include/net/switchdev.h
>>> @@ -16,6 +16,7 @@
>>> int netdev_switch_parent_id_get(struct net_device *dev,
>>> struct netdev_phys_item_id *psid);
>>> +int netdev_switch_port_stp_update(struct net_device *dev, u8 state);
>>> #else
>>> @@ -25,6 +26,12 @@ static inline int netdev_switch_parent_id_get(struct
>>> net_device *dev,
>>> return -EOPNOTSUPP;
>>> }
>>> +static inline int netdev_switch_port_stp_update(struct net_device *dev,
>>> + u8 state)
>>> +{
>>> + return -EOPNOTSUPP;
>>> +}
>>> +
>>> #endif
>>> #endif /* _LINUX_SWITCHDEV_H_ */
>>> diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
>>> index 2b047bc..35e016c 100644
>>> --- a/net/bridge/br_stp.c
>>> +++ b/net/bridge/br_stp.c
>>> @@ -12,6 +12,7 @@
>>> */
>>> #include <linux/kernel.h>
>>> #include <linux/rculist.h>
>>> +#include <net/switchdev.h>
>>> #include "br_private.h"
>>> #include "br_private_stp.h"
>>> @@ -39,6 +40,7 @@ void br_log_state(const struct net_bridge_port *p)
>>> void br_set_state(struct net_bridge_port *p, unsigned int state)
>>> {
>>> p->state = state;
>>> + netdev_switch_port_stp_update(p->dev, state);
>>> }
>>> /* called under bridge lock */
>>> diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
>>> index 66973de..d162b21 100644
>>> --- a/net/switchdev/switchdev.c
>>> +++ b/net/switchdev/switchdev.c
>>> @@ -31,3 +31,22 @@ int netdev_switch_parent_id_get(struct net_device *dev,
>>> return ops->ndo_switch_parent_id_get(dev, psid);
>>> }
>>> EXPORT_SYMBOL(netdev_switch_parent_id_get);
>>> +
>>> +/**
>>> + * netdev_switch_port_stp_update - Notify switch device port of STP
>>> + * state change
>>> + * @dev: port device
>>> + * @state: port STP state
>>> + *
>>> + * Notify switch device port of bridge port STP state change.
>>> + */
>>> +int netdev_switch_port_stp_update(struct net_device *dev, u8 state)
>>> +{
>>> + const struct net_device_ops *ops = dev->netdev_ops;
>>> +
>>> + if (!ops->ndo_switch_port_stp_update)
>>> + return -EOPNOTSUPP;
>>> + WARN_ON(!ops->ndo_switch_parent_id_get);
>>> + return ops->ndo_switch_port_stp_update(dev, state);
>>> +}
>>> +EXPORT_SYMBOL(netdev_switch_port_stp_update);
>>
>> This should also check if offload is enabled on the bridge/port ?
>>
^ permalink raw reply
* [PATCH] Documentation: bindings: net: DPAA corenet binding document
From: Madalin Bucur @ 2014-11-28 10:10 UTC (permalink / raw)
To: devicetree, linuxppc-dev, netdev
Cc: scottwood, Emilian.Medve, Igal.Liberman, Madalin Bucur
Add the device tree binding document for the DPAA corenet node
and DPAA Ethernet nodes.
Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
---
Documentation/devicetree/bindings/net/fsl-dpaa.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/fsl-dpaa.txt
diff --git a/Documentation/devicetree/bindings/net/fsl-dpaa.txt b/Documentation/devicetree/bindings/net/fsl-dpaa.txt
new file mode 100644
index 0000000..822c668
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl-dpaa.txt
@@ -0,0 +1,31 @@
+*DPAA corenet
+
+The corenet bus containing all DPAA Ethernet nodes.
+
+Required property
+ - compatible: string property. Must include "fsl,dpaa". Can include
+ also "fsl,<SoC>-dpaa".
+
+Example:
+
+fsl,dpaa {
+ compatible = "fsl,p4080-dpaa", "fsl,dpaa";
+};
+
+*DPAA Ethernet
+
+DPAA Ethernet implements an Ethernet interface on top of the functionality
+offered by the DPAA accelerators: QMan, BMan, FMan. It contains a reference
+to the FMan MAC node used (dTSEC, TGEC, MEMAC). This construct is used by
+u-boot for the boot-time device tree fix-up.
+
+Required properties
+ - compatible: standard string property. Must include "fsl,dpa-ethernet".
+ - fsl,fman-mac: phandle that references a node describing the used DPAA MAC.
+
+Example:
+
+ethernet0 {
+ compatible = "fsl,dpa-ethernet";
+ fsl,fman-mac = <&enet0>;
+};
--
1.7.11.7
^ permalink raw reply related
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Roopa Prabhu @ 2014-11-28 10:14 UTC (permalink / raw)
To: Scott Feldman
Cc: Jamal Hadi Salim, John Fastabend, Jiri Pirko, Netdev,
David S. Miller, nhorman@tuxdriver.com, Andy Gospodarek,
Thomas Graf, dborkman@redhat.com, ogerlitz@mellanox.com,
jesse@nicira.com, pshelar@nicira.com, azhou@nicira.com,
ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang, Eric Dumazet,
Florian Fainelli, John Linville, "j
In-Reply-To: <CAE4R7bD1Hi+fnKp-Sg6Tn4AcpOu2pwgEYecP8LVA1ioO4FkgRQ@mail.gmail.com>
On 11/25/14, 6:36 PM, Scott Feldman wrote:
> On Tue, Nov 25, 2014 at 6:50 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>> On 11/25/14 11:30, John Fastabend wrote:
>>> On 11/25/2014 08:18 AM, Jamal Hadi Salim wrote:
>>>> On 11/25/14 11:01, John Fastabend wrote:
>>>>> On 11/25/2014 07:38 AM, Jamal Hadi Salim wrote:
>>>>>> On 11/25/14 05:28, Jiri Pirko wrote:
>>>>>>> Do the work of parsing NDA_VLAN directly in rtnetlink code, pass
>>>>>>> simple
>>>>>>> u16 vid to drivers from there.
>>>>>>>
>>
>>> Actually (after having some coffee) this becomes much more useful
>>> if you return which items failed. Then you can slam the hardware
>>> with your 100 entries, probably a lot more then that, and come back
>>> later and clean it up.
>>>
>> Yes, that is the general use case.
>> Unfortunately at the moment we only return codes on a netlink set
>> direction - but would be a beauty if we could return what succeeded
>> and didnt in some form of vector.
>> Note: all is not lost because you can always do a get afterwards and
>> find what is missing if you got a return code of "partial success".
>> Just a little less efficient..
>>
>>
>>> We return a bitmask of which operations were successful. So if SW fails
>>> we have both bits cleared and we abort. When SW is successful we set the
>>> SW bit and try to program the HW. If its sucessful we set the HW bit if
>>> its not we abort with an err. Converting this to (1) is not much work
>>> just skip the abort.
>>>
>> Ok, guess i am gonna have to go stare at the code some more.
>> I thought we returned one of the error codes?
>> A bitmask would work for a single entry - because you have two
>> options add to h/ware and/or s/ware. So response is easy to encode.
>> But if i have 1000 and they are sparsely populated (think an indexed
>> table and i have indices 1, 23, 45, etc), then a bitmask would be
>> hard to use.
> I'm confused by this discussion. Do I have this right: You want to
> send 1000 RTM_NEWNEIGHs to PF_BRIDGE with both NTF_MASTER and NTF_SELF
> set such that 1000 new FBD entries are installed in both (SW) the
> bridge's FDB and (HW) the port driver's FDB. My first confusion is
> why do you want these FBD entries in bridge's FDB? We're offloading
> the switching to HW so HW should be handling fwd plane. If ctrl pkt
> make it to SW, it can learn those FDB entries; no need for manual
> install of FDB entry in SW. It seems to me you only want to use
> NTF_SELF to install the FDB entry in HW using the port driver. And an
> error code is returned for that install. Since there is only one
> target (NTF_SELF) there is no need for bitmask return.
>
scott, we do have such usecase today. ie , a fdb entry with both
NTF_MASTER and NTF_SELF set.
And these fdb entries can come from an external controller. The path to
get them to the hw is via the kernel.
The controller can use `bridge fdb add` to add the fdb entries to the
kernel (with NTF_MASTER) and also indicate in the same message to add
the fdb entry to hw (with NTF_SELF). And in this model it is assumed
that the kernel fdb and hw fdb are in sync.
^ permalink raw reply
* Re: [PATCH net-next] bridge: add vlan id to mdb notifications
From: Roopa Prabhu @ 2014-11-28 10:18 UTC (permalink / raw)
To: Thomas Graf
Cc: Stephen Hemminger, vyasevich, netdev, wkok, gospo, jtoppins,
sashok, Shrijeet Mukherjee
In-Reply-To: <20141126215327.GC13786@casper.infradead.org>
On 11/26/14, 1:53 PM, Thomas Graf wrote:
> On 11/26/14 at 12:40pm, Roopa Prabhu wrote:
>> I have always wondered, if binary netlink attributes have this restriction,
>> they should be discouraged. especially when the other extensible option is
>> to add them as a separate netlink attribute.
> This is pretty much exactly the reason why attributes have been
> introduced ;-)
thanks for confirming that thomas :). Will resubmit the patch with vlan
information as a separate attribute.
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-11-28 10:27 UTC (permalink / raw)
To: Bjørn Mork
Cc: Alex Strizhevsky, ShaojunMidge.Tan, Mingying.Zhu, youtux,
linux-usb, netdev, Eli.Britstein
In-Reply-To: <87ppc71xne.fsf@nemi.mork.no>
... and what do you think regarding the last arp packet Kevin shared with us
after having changed the remainder fixed value.
^ permalink raw reply
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Scott Feldman @ 2014-11-28 10:33 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jamal Hadi Salim, John Fastabend, Jiri Pirko, Netdev,
David S. Miller, nhorman@tuxdriver.com, Andy Gospodarek,
Thomas Graf, dborkman@redhat.com, ogerlitz@mellanox.com,
jesse@nicira.com, pshelar@nicira.com, azhou@nicira.com,
ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang, Eric Dumazet,
Florian Fainelli, John Linville, "j
In-Reply-To: <54784B1D.8090508@cumulusnetworks.com>
On Fri, Nov 28, 2014 at 2:14 AM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> On 11/25/14, 6:36 PM, Scott Feldman wrote:
>>
>> On Tue, Nov 25, 2014 at 6:50 AM, Jamal Hadi Salim <jhs@mojatatu.com>
>> wrote:
>>>
>>> On 11/25/14 11:30, John Fastabend wrote:
>>>>
>>>> On 11/25/2014 08:18 AM, Jamal Hadi Salim wrote:
>>>>>
>>>>> On 11/25/14 11:01, John Fastabend wrote:
>>>>>>
>>>>>> On 11/25/2014 07:38 AM, Jamal Hadi Salim wrote:
>>>>>>>
>>>>>>> On 11/25/14 05:28, Jiri Pirko wrote:
>>>>>>>>
>>>>>>>> Do the work of parsing NDA_VLAN directly in rtnetlink code, pass
>>>>>>>> simple
>>>>>>>> u16 vid to drivers from there.
>>>>>>>>
>>>
>>>> Actually (after having some coffee) this becomes much more useful
>>>> if you return which items failed. Then you can slam the hardware
>>>> with your 100 entries, probably a lot more then that, and come back
>>>> later and clean it up.
>>>>
>>> Yes, that is the general use case.
>>> Unfortunately at the moment we only return codes on a netlink set
>>> direction - but would be a beauty if we could return what succeeded
>>> and didnt in some form of vector.
>>> Note: all is not lost because you can always do a get afterwards and
>>> find what is missing if you got a return code of "partial success".
>>> Just a little less efficient..
>>>
>>>
>>>> We return a bitmask of which operations were successful. So if SW fails
>>>> we have both bits cleared and we abort. When SW is successful we set the
>>>> SW bit and try to program the HW. If its sucessful we set the HW bit if
>>>> its not we abort with an err. Converting this to (1) is not much work
>>>> just skip the abort.
>>>>
>>> Ok, guess i am gonna have to go stare at the code some more.
>>> I thought we returned one of the error codes?
>>> A bitmask would work for a single entry - because you have two
>>> options add to h/ware and/or s/ware. So response is easy to encode.
>>> But if i have 1000 and they are sparsely populated (think an indexed
>>> table and i have indices 1, 23, 45, etc), then a bitmask would be
>>> hard to use.
>>
>> I'm confused by this discussion. Do I have this right: You want to
>> send 1000 RTM_NEWNEIGHs to PF_BRIDGE with both NTF_MASTER and NTF_SELF
>> set such that 1000 new FBD entries are installed in both (SW) the
>> bridge's FDB and (HW) the port driver's FDB. My first confusion is
>> why do you want these FBD entries in bridge's FDB? We're offloading
>> the switching to HW so HW should be handling fwd plane. If ctrl pkt
>> make it to SW, it can learn those FDB entries; no need for manual
>> install of FDB entry in SW. It seems to me you only want to use
>> NTF_SELF to install the FDB entry in HW using the port driver. And an
>> error code is returned for that install. Since there is only one
>> target (NTF_SELF) there is no need for bitmask return.
>>
> scott, we do have such usecase today. ie , a fdb entry with both NTF_MASTER
> and NTF_SELF set.
> And these fdb entries can come from an external controller. The path to get
> them to the hw is via the kernel.
> The controller can use `bridge fdb add` to add the fdb entries to the kernel
> (with NTF_MASTER) and also indicate in the same message to add the fdb entry
> to hw (with NTF_SELF). And in this model it is assumed that the kernel fdb
> and hw fdb are in sync.
Ya, I understood that from Jamal's explanation.
^ permalink raw reply
* RE: [PATCH iproute2] ip xfrm: support 64bit kernel and 32bit userspace
From: David Laight @ 2014-11-28 10:47 UTC (permalink / raw)
To: 'roy.qing.li@gmail.com', netdev@vger.kernel.org
In-Reply-To: <1417157936-5522-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
> From: Li RongQing <roy.qing.li@gmail.com>
>
> The size of struct xfrm_userpolicy_info is 168 bytes for 64bit kernel, and
> 164 bytes for 32bit userspace because of the different alignment. and lead
> to "ip xfrm" be unable to work.
>
> add a pad in struct xfrm_userpolicy_info, and enable it by set
> KERNEL_64_USERSPACE_32 to y
...
> diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
> index fa2ecb2..009510c 100644
> --- a/include/linux/xfrm.h
> +++ b/include/linux/xfrm.h
> @@ -407,6 +407,9 @@ struct xfrm_userpolicy_info {
> /* Automatically expand selector to include matching ICMP payloads. */
> #define XFRM_POLICY_ICMP 2
> __u8 share;
> +#ifdef KNL_64_US_32
> + int pad;
> +#endif
> };
You could add __attribute__((aligned(8))) to the structure to pad it on
all systems.
Or find the 64bit member and add __attribute__((aligned(4))) to that member
so that the 64bit version doesn't get padded.
That will make the field more expensive to access on systems that can't
do misaligned memory transfers.
David
^ permalink raw reply
* Re: [patch net-next v3 08/17] bridge: call netdev_sw_port_stp_update when bridge port STP status changes
From: Scott Feldman @ 2014-11-28 10:51 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiri Pirko, Netdev, David S. Miller, nhorman@tuxdriver.com,
Andy Gospodarek, Thomas Graf, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Jamal Hadi Salim,
Florian Fainelli, John Linville
In-Reply-To: <547848D8.1060203@cumulusnetworks.com>
On Fri, Nov 28, 2014 at 2:05 AM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> On 11/25/14, 5:35 PM, Scott Feldman wrote:
>>
>> The
>> bridge driver or external STP process (msptd) is still controlling STP
>> state for the port and processing the BPDUs. When the state changes
>> on the port, the bridge driver is letting HW know, that's it.
>
>
> I understand that. In which case, we should not call it stp state.
> It is just port state.
Sure, call it port state but it takes on BR_STATE_xxx values which
just so happen to correspond exactly to STP states.
> And since it is yet another port attribute like port
> priority,
> we should be able to use the same api to offload it to hw just like the
> other port attributes.
Well it does...see ndo_bridge_setlink in bridge driver, br_setport
where IFLA_BRPORT_STATE is handled...it calls br_set_port_state(),
which calls into the swdev port driver. That's for the case where
user or external processing is setting STP state. For the case where
the bridge itself is managing the STP state, the bridge will make the
same br_set_port_state() call to adjust the port state.
> And, Thats why i tried to generalize all bridge port attribute set by
> introducing one generic netdev_sw_port_set_attr api.
> https://marc.info/?l=linux-netdev&m=141661018619712&w=2
>
>
> And coming back to my original comment in this thread,
> the port state should be offloaded to hw only when the swdev mode (or hw
> offload mode ;) is set.
>
>
>> If the
>> port driver can't do anything with that notification, then it should
>> not implement ndo_switch_port_stp_update. If it does implement
>> ndo_switch_port_stp_update, then it can adjust its HW (e.g. disable
>> port if BR_DISABLED, etc), and return err code if somehow it failed
>> while adjusting HW.
>>
>> This is not offloading STP state ctrl plane to HW. The ctrl plane is
>> kept in bridge driver (or mstpd) in SW. HW stays dumb in this model.
>> The bridge currently has policy control to turn on/off STP per bridge
>> and a netlink hook for external processes to change STP state.
>>
>> On Tue, Nov 25, 2014 at 12:48 PM, Roopa Prabhu
>> <roopa@cumulusnetworks.com> wrote:
>>>
>>> On 11/25/14, 2:28 AM, Jiri Pirko wrote:
>>>>
>>>> From: Scott Feldman <sfeldma@gmail.com>
>>>>
>>>> To notify switch driver of change in STP state of bridge port, add new
>>>> .ndo op and provide switchdev wrapper func to call ndo op. Use it in
>>>> bridge
>>>> code then.
>>>>
>>>> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>>>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>>> ---
>>>> v2->v3:
>>>> -changed "sw" string to "switch" to avoid confusion
>>>> v1->v2:
>>>> -no change
>>>> ---
>>>> include/linux/netdevice.h | 5 +++++
>>>> include/net/switchdev.h | 7 +++++++
>>>> net/bridge/br_stp.c | 2 ++
>>>> net/switchdev/switchdev.c | 19 +++++++++++++++++++
>>>> 4 files changed, 33 insertions(+)
>>>>
>>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>>> index ce096dc..66cb64e 100644
>>>> --- a/include/linux/netdevice.h
>>>> +++ b/include/linux/netdevice.h
>>>> @@ -1024,6 +1024,9 @@ typedef u16 (*select_queue_fallback_t)(struct
>>>> net_device *dev,
>>>> * Called to get an ID of the switch chip this port is part of.
>>>> * If driver implements this, it indicates that it represents a
>>>> port
>>>> * of a switch chip.
>>>> + * int (*ndo_switch_port_stp_update)(struct net_device *dev, u8 state);
>>>> + * Called to notify switch device port of bridge port STP
>>>> + * state change.
>>>> */
>>>> struct net_device_ops {
>>>> int (*ndo_init)(struct net_device *dev);
>>>> @@ -1180,6 +1183,8 @@ struct net_device_ops {
>>>> #ifdef CONFIG_NET_SWITCHDEV
>>>> int (*ndo_switch_parent_id_get)(struct
>>>> net_device *dev,
>>>> struct
>>>> netdev_phys_item_id *psid);
>>>> + int (*ndo_switch_port_stp_update)(struct
>>>> net_device *dev,
>>>> + u8 state);
>>>> #endif
>>>> };
>>>> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
>>>> index 7a52360..8a6d164 100644
>>>> --- a/include/net/switchdev.h
>>>> +++ b/include/net/switchdev.h
>>>> @@ -16,6 +16,7 @@
>>>> int netdev_switch_parent_id_get(struct net_device *dev,
>>>> struct netdev_phys_item_id *psid);
>>>> +int netdev_switch_port_stp_update(struct net_device *dev, u8 state);
>>>> #else
>>>> @@ -25,6 +26,12 @@ static inline int
>>>> netdev_switch_parent_id_get(struct
>>>> net_device *dev,
>>>> return -EOPNOTSUPP;
>>>> }
>>>> +static inline int netdev_switch_port_stp_update(struct net_device
>>>> *dev,
>>>> + u8 state)
>>>> +{
>>>> + return -EOPNOTSUPP;
>>>> +}
>>>> +
>>>> #endif
>>>> #endif /* _LINUX_SWITCHDEV_H_ */
>>>> diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
>>>> index 2b047bc..35e016c 100644
>>>> --- a/net/bridge/br_stp.c
>>>> +++ b/net/bridge/br_stp.c
>>>> @@ -12,6 +12,7 @@
>>>> */
>>>> #include <linux/kernel.h>
>>>> #include <linux/rculist.h>
>>>> +#include <net/switchdev.h>
>>>> #include "br_private.h"
>>>> #include "br_private_stp.h"
>>>> @@ -39,6 +40,7 @@ void br_log_state(const struct net_bridge_port *p)
>>>> void br_set_state(struct net_bridge_port *p, unsigned int state)
>>>> {
>>>> p->state = state;
>>>> + netdev_switch_port_stp_update(p->dev, state);
>>>> }
>>>> /* called under bridge lock */
>>>> diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
>>>> index 66973de..d162b21 100644
>>>> --- a/net/switchdev/switchdev.c
>>>> +++ b/net/switchdev/switchdev.c
>>>> @@ -31,3 +31,22 @@ int netdev_switch_parent_id_get(struct net_device
>>>> *dev,
>>>> return ops->ndo_switch_parent_id_get(dev, psid);
>>>> }
>>>> EXPORT_SYMBOL(netdev_switch_parent_id_get);
>>>> +
>>>> +/**
>>>> + * netdev_switch_port_stp_update - Notify switch device port of STP
>>>> + * state change
>>>> + * @dev: port device
>>>> + * @state: port STP state
>>>> + *
>>>> + * Notify switch device port of bridge port STP state change.
>>>> + */
>>>> +int netdev_switch_port_stp_update(struct net_device *dev, u8 state)
>>>> +{
>>>> + const struct net_device_ops *ops = dev->netdev_ops;
>>>> +
>>>> + if (!ops->ndo_switch_port_stp_update)
>>>> + return -EOPNOTSUPP;
>>>> + WARN_ON(!ops->ndo_switch_parent_id_get);
>>>> + return ops->ndo_switch_port_stp_update(dev, state);
>>>> +}
>>>> +EXPORT_SYMBOL(netdev_switch_port_stp_update);
>>>
>>>
>>> This should also check if offload is enabled on the bridge/port ?
>>>
>
^ permalink raw reply
* Re: [patch net-next v4 00/21] introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload
From: Scott Feldman @ 2014-11-28 11:59 UTC (permalink / raw)
To: Jiri Pirko
Cc: Netdev, David S. Miller, nhorman@tuxdriver.com, Andy Gospodarek,
Thomas Graf, dborkman@redhat.com, ogerlitz@mellanox.com,
jesse@nicira.com, pshelar@nicira.com, azhou@nicira.com,
ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Jamal Hadi Salim,
Florian Fainelli, Roopa Prabhu, John Linville
In-Reply-To: <1417084826-9875-1-git-send-email-jiri@resnulli.us>
Thanks Jiri for coordinating this effort. It looks like we're close
to convergence on this first patch set. I sifted thru review comments
and compiled a list of items for follow-on work. I hope it's OK to
use etherpad for this:
https://etherpad.wikimedia.org/p/netdev-swdev-todo
Feel free to edit as needed and claim an item if you intend to work on
it. Don't turn the etherpad into a discussion board...try to keep it
as list of work items. I don't think any of these items should hold
up current patch set.
-scott
On Thu, Nov 27, 2014 at 2:40 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> Hi all.
>
> This patchset is just the first phase of switch and switch-ish device
> support api in kernel. Note that the api will extend.
>
> So what this patchset includes:
> - introduce switchdev api skeleton for implementing switch drivers
> - introduce rocker switch driver which implements switchdev api fdb and
> bridge set/get link ndos
>
> As to the discussion if there is need to have specific class of device
> representing the switch itself, so far we found no need to introduce that.
> But we are generally ok with the idea and when the time comes and it will
> be needed, it can be easily introduced without any disturbance.
>
> This patchset introduces switch id export through rtnetlink and sysfs,
> which is similar to what we have for port id in SR-IOV. I will send iproute2
> patchset for showing the switch id for port netdevs once this is applied.
> This applies also for the PF_BRIDGE and fdb iproute2 patches.
>
> iproute2 patches are now available here:
> https://github.com/jpirko/iproute2-rocker
>
> For detailed description and version history, please see individual patches.
>
> In v4 I reordered the patches leaving rocker patches on the end of the patchset.
>
> Jiri Pirko (10):
> bridge: rename fdb_*_hw to fdb_*_hw_addr to avoid confusion
> neigh: sort Neighbor Cache Entry Flags
> bridge: convert flags in fbd entry into bitfields
> net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
> net: rename netdev_phys_port_id to more generic name
> net: introduce generic switch devices support
> rtnl: expose physical switch id for particular device
> net-sysfs: expose physical switch id for particular device
> rocker: introduce rocker switch driver
> rocker: implement ndo_fdb_dump
>
> Scott Feldman (9):
> bridge: call netdev_sw_port_stp_update when bridge port STP status
> changes
> bridge: add API to notify bridge driver of learned FBD on offloaded
> device
> bridge: move private brport flags to if_bridge.h so port drivers can
> use flags
> bridge: add new brport flag LEARNING_SYNC
> bridge: add new hwmode swdev
> bridge: add brport flags to dflt bridge_getlink
> rocker: implement rocker ofdpa flow table manipulation
> rocker: implement L2 bridge offloading
> rocker: add ndo_bridge_setlink/getlink support for learning policy
>
> Thomas Graf (2):
> rocker: Add proper validation of Netlink attributes
> rocker: Use logical operators on booleans
>
> Documentation/ABI/testing/sysfs-class-net | 8 +
> Documentation/networking/switchdev.txt | 59 +
> MAINTAINERS | 14 +
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
> drivers/net/ethernet/emulex/benet/be_main.c | 3 +-
> drivers/net/ethernet/intel/i40e/i40e_main.c | 4 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +-
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 11 +-
> drivers/net/ethernet/rocker/Kconfig | 27 +
> drivers/net/ethernet/rocker/Makefile | 5 +
> drivers/net/ethernet/rocker/rocker.c | 4374 ++++++++++++++++++++++
> drivers/net/ethernet/rocker/rocker.h | 428 +++
> drivers/net/macvlan.c | 4 +-
> drivers/net/vxlan.c | 4 +-
> include/linux/if_bridge.h | 31 +
> include/linux/netdevice.h | 39 +-
> include/linux/rtnetlink.h | 9 +-
> include/net/switchdev.h | 37 +
> include/uapi/linux/if_bridge.h | 1 +
> include/uapi/linux/if_link.h | 2 +
> include/uapi/linux/neighbour.h | 6 +-
> net/Kconfig | 1 +
> net/Makefile | 3 +
> net/bridge/br_fdb.c | 144 +-
> net/bridge/br_private.h | 21 +-
> net/bridge/br_stp.c | 7 +
> net/core/dev.c | 2 +-
> net/core/net-sysfs.c | 26 +-
> net/core/rtnetlink.c | 119 +-
> net/switchdev/Kconfig | 13 +
> net/switchdev/Makefile | 5 +
> net/switchdev/switchdev.c | 52 +
> 35 files changed, 5366 insertions(+), 105 deletions(-)
> create mode 100644 Documentation/networking/switchdev.txt
> create mode 100644 drivers/net/ethernet/rocker/Kconfig
> create mode 100644 drivers/net/ethernet/rocker/Makefile
> create mode 100644 drivers/net/ethernet/rocker/rocker.c
> create mode 100644 drivers/net/ethernet/rocker/rocker.h
> create mode 100644 include/net/switchdev.h
> create mode 100644 net/switchdev/Kconfig
> create mode 100644 net/switchdev/Makefile
> create mode 100644 net/switchdev/switchdev.c
>
> --
> 1.9.3
>
^ permalink raw reply
* Re: [patch net-next v4 00/21] introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload
From: Jiri Pirko @ 2014-11-28 12:07 UTC (permalink / raw)
To: Scott Feldman
Cc: Netdev, David S. Miller, nhorman@tuxdriver.com, Andy Gospodarek,
Thomas Graf, dborkman@redhat.com, ogerlitz@mellanox.com,
jesse@nicira.com, pshelar@nicira.com, azhou@nicira.com,
ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Jamal Hadi Salim,
Florian Fainelli, Roopa Prabhu, John Linville
In-Reply-To: <CAE4R7bDNbyfxx+XExmej8-p=E3X4cHc+Sr75S=aO67XMYcmU8g@mail.gmail.com>
Fri, Nov 28, 2014 at 12:59:17PM CET, sfeldma@gmail.com wrote:
>Thanks Jiri for coordinating this effort. It looks like we're close
>to convergence on this first patch set. I sifted thru review comments
>and compiled a list of items for follow-on work. I hope it's OK to
>use etherpad for this:
>
>https://etherpad.wikimedia.org/p/netdev-swdev-todo
>
>Feel free to edit as needed and claim an item if you intend to work on
>it. Don't turn the etherpad into a discussion board...try to keep it
>as list of work items. I don't think any of these items should hold
>up current patch set.
Agree. Good idea putting the todo list on etherpad.
So I will post v5 just with the whitespace issue fixed (pointed out by
Sergei Shtylyov).
Thanks.
>
>-scott
>
>On Thu, Nov 27, 2014 at 2:40 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Hi all.
>>
>> This patchset is just the first phase of switch and switch-ish device
>> support api in kernel. Note that the api will extend.
>>
>> So what this patchset includes:
>> - introduce switchdev api skeleton for implementing switch drivers
>> - introduce rocker switch driver which implements switchdev api fdb and
>> bridge set/get link ndos
>>
>> As to the discussion if there is need to have specific class of device
>> representing the switch itself, so far we found no need to introduce that.
>> But we are generally ok with the idea and when the time comes and it will
>> be needed, it can be easily introduced without any disturbance.
>>
>> This patchset introduces switch id export through rtnetlink and sysfs,
>> which is similar to what we have for port id in SR-IOV. I will send iproute2
>> patchset for showing the switch id for port netdevs once this is applied.
>> This applies also for the PF_BRIDGE and fdb iproute2 patches.
>>
>> iproute2 patches are now available here:
>> https://github.com/jpirko/iproute2-rocker
>>
>> For detailed description and version history, please see individual patches.
>>
>> In v4 I reordered the patches leaving rocker patches on the end of the patchset.
>>
>> Jiri Pirko (10):
>> bridge: rename fdb_*_hw to fdb_*_hw_addr to avoid confusion
>> neigh: sort Neighbor Cache Entry Flags
>> bridge: convert flags in fbd entry into bitfields
>> net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
>> net: rename netdev_phys_port_id to more generic name
>> net: introduce generic switch devices support
>> rtnl: expose physical switch id for particular device
>> net-sysfs: expose physical switch id for particular device
>> rocker: introduce rocker switch driver
>> rocker: implement ndo_fdb_dump
>>
>> Scott Feldman (9):
>> bridge: call netdev_sw_port_stp_update when bridge port STP status
>> changes
>> bridge: add API to notify bridge driver of learned FBD on offloaded
>> device
>> bridge: move private brport flags to if_bridge.h so port drivers can
>> use flags
>> bridge: add new brport flag LEARNING_SYNC
>> bridge: add new hwmode swdev
>> bridge: add brport flags to dflt bridge_getlink
>> rocker: implement rocker ofdpa flow table manipulation
>> rocker: implement L2 bridge offloading
>> rocker: add ndo_bridge_setlink/getlink support for learning policy
>>
>> Thomas Graf (2):
>> rocker: Add proper validation of Netlink attributes
>> rocker: Use logical operators on booleans
>>
>> Documentation/ABI/testing/sysfs-class-net | 8 +
>> Documentation/networking/switchdev.txt | 59 +
>> MAINTAINERS | 14 +
>> drivers/net/ethernet/Kconfig | 1 +
>> drivers/net/ethernet/Makefile | 1 +
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
>> drivers/net/ethernet/emulex/benet/be_main.c | 3 +-
>> drivers/net/ethernet/intel/i40e/i40e_main.c | 4 +-
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +-
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
>> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 11 +-
>> drivers/net/ethernet/rocker/Kconfig | 27 +
>> drivers/net/ethernet/rocker/Makefile | 5 +
>> drivers/net/ethernet/rocker/rocker.c | 4374 ++++++++++++++++++++++
>> drivers/net/ethernet/rocker/rocker.h | 428 +++
>> drivers/net/macvlan.c | 4 +-
>> drivers/net/vxlan.c | 4 +-
>> include/linux/if_bridge.h | 31 +
>> include/linux/netdevice.h | 39 +-
>> include/linux/rtnetlink.h | 9 +-
>> include/net/switchdev.h | 37 +
>> include/uapi/linux/if_bridge.h | 1 +
>> include/uapi/linux/if_link.h | 2 +
>> include/uapi/linux/neighbour.h | 6 +-
>> net/Kconfig | 1 +
>> net/Makefile | 3 +
>> net/bridge/br_fdb.c | 144 +-
>> net/bridge/br_private.h | 21 +-
>> net/bridge/br_stp.c | 7 +
>> net/core/dev.c | 2 +-
>> net/core/net-sysfs.c | 26 +-
>> net/core/rtnetlink.c | 119 +-
>> net/switchdev/Kconfig | 13 +
>> net/switchdev/Makefile | 5 +
>> net/switchdev/switchdev.c | 52 +
>> 35 files changed, 5366 insertions(+), 105 deletions(-)
>> create mode 100644 Documentation/networking/switchdev.txt
>> create mode 100644 drivers/net/ethernet/rocker/Kconfig
>> create mode 100644 drivers/net/ethernet/rocker/Makefile
>> create mode 100644 drivers/net/ethernet/rocker/rocker.c
>> create mode 100644 drivers/net/ethernet/rocker/rocker.h
>> create mode 100644 include/net/switchdev.h
>> create mode 100644 net/switchdev/Kconfig
>> create mode 100644 net/switchdev/Makefile
>> create mode 100644 net/switchdev/switchdev.c
>>
>> --
>> 1.9.3
>>
^ permalink raw reply
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Jamal Hadi Salim @ 2014-11-28 12:57 UTC (permalink / raw)
To: Jiri Pirko, Scott Feldman
Cc: John Fastabend, Netdev, David S. Miller, nhorman@tuxdriver.com,
Andy Gospodarek, Thomas Graf, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang, Eric Dumazet,
Florian Fainelli, Roopa Prabhu, John Linville,
"jasowang@redhat.com" <jasow
In-Reply-To: <20141127215529.GA17784@nanopsycho.orion>
On 11/27/14 16:55, Jiri Pirko wrote:
> Thu, Nov 27, 2014 at 09:59:37PM CET, sfeldma@gmail.com wrote:
>> Ya right now the driver just doesn't call br_fdb_external_learn_add()
>> if LEARNING_SYNC is not set. It's a port driver setting so it seems
>> fine to handle it in the port driver. You could move the check up to
>> br_fdb_external_learn_add(), but then you have an extra call every 1s
>> for each fdb entry being refreshed. (1s or whatever the refresh
>> frequency is). Easier to avoid this overhead and make the decision at
>> the source.
>
> I have been thinking about moving the check into bridge code, it to make
> it there as well as in drivers. This is easily changeable on demenad
> later though, so I left this for now.
>
It seems more comfortable to move to the core if you are doing polling
with timers... i.e you kick it per-offload via some timer. The arming
being done by the setting of LEARNING_SYNC
There are cases where all this is done via interrupts. i.e the hardware
will issue an interrupt only then do you poll..
Maybe Scott's approach is the correct one. I am indifferent to be
honest, these are some of those things that can be easily refactored
as more hardware shows up.
cheers,
jamal
^ permalink raw reply
* [PATCH] cxgb4: Fill in supported link mode for SFP modules
From: Hariprasad Shenai @ 2014-11-28 13:05 UTC (permalink / raw)
To: netdev; +Cc: davem, leedom, nirranjan, Hariprasad Shenai
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 605eaab..279275d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -2362,9 +2362,13 @@ static unsigned int from_fw_linkcaps(unsigned int type, unsigned int caps)
SUPPORTED_10000baseKR_Full | SUPPORTED_1000baseKX_Full |
SUPPORTED_10000baseKX4_Full;
else if (type == FW_PORT_TYPE_FIBER_XFI ||
- type == FW_PORT_TYPE_FIBER_XAUI || type == FW_PORT_TYPE_SFP)
+ type == FW_PORT_TYPE_FIBER_XAUI || type == FW_PORT_TYPE_SFP) {
v |= SUPPORTED_FIBRE;
- else if (type == FW_PORT_TYPE_BP40_BA)
+ if (caps & FW_PORT_CAP_SPEED_1G)
+ v |= SUPPORTED_1000baseT_Full;
+ if (caps & FW_PORT_CAP_SPEED_10G)
+ v |= SUPPORTED_10000baseT_Full;
+ } else if (type == FW_PORT_TYPE_BP40_BA)
v |= SUPPORTED_40000baseSR4_Full;
if (caps & FW_PORT_CAP_ANEG)
--
1.7.1
^ permalink raw reply related
* Re: [patch net-next v4 14/21] bridge: add brport flags to dflt bridge_getlink
From: Jamal Hadi Salim @ 2014-11-28 13:07 UTC (permalink / raw)
To: Scott Feldman
Cc: Jiri Pirko, Netdev, David S. Miller, nhorman@tuxdriver.com,
Andy Gospodarek, Thomas Graf, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Florian Fainelli, Roopa Prabhu,
John Linville
In-Reply-To: <CAE4R7bBqAg0CoEcz0s6MKnCH60YEk3EMDD875H_p4GtRhGMGUQ@mail.gmail.com>
On 11/27/14 15:46, Scott Feldman wrote:
> On Thu, Nov 27, 2014 at 3:17 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
> For RTM_GETLINK, rtnl_bridge_getlink() calls ndo_bridge_getlink twice
> for each dev, once on bridge and second time on dev. Each call adds
> an RTM_NEWLINK to skb. For the ndo_bridge_getlink() call to bridge,
> the MASTER port flags are filled in using br_port_fill_attr(). For
> the second ndo_bridge_getlink() call to dev, the port driver calls
> ndo_dflt_bridge_getlink() which fills in the SELF port flags. Before
> this patch, ndo_dflt_bridge_getlink() was only filling in hwmode.
>
> Whew, in any case, I think you'll agree this code needs a refactoring
> down the road. This change is just the bare minimum building on
> what's there to get SELF port flags up to user-space. A refactoring
> effort should get the port drivers out of parsing/filling netlink msg
> and leave that to the core code in rtnetlink.c. That way we can have
> one place for policy checks and one place for fill. I think this
> refactoring effort should be left out in this patch series, otherwise
> this is going to drag on into the next year.
>
I am fine with that. At minimal br_port_fill_attr() is reusable.
There's a lot of stuff i wish would be "fixed" - one is clearly
not abusing a u8 just to send one bit to the kernel. You just
added one more horn of that sort with the sync learning.
I wish i had time to clean it up. In any case:
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 04/17] net: introduce generic switch devices support
From: Jamal Hadi Salim @ 2014-11-28 13:13 UTC (permalink / raw)
To: Jiri Pirko
Cc: Thomas Graf, Scott Feldman, Netdev, David S. Miller,
nhorman@tuxdriver.com, Andy Gospodarek, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Florian Fainelli, Roopa Prabhu,
John Linville
In-Reply-To: <20141127135050.GD1877@nanopsycho.orion>
On 11/27/14 08:50, Jiri Pirko wrote:
> $ git grep offload net
> Wouldn't it be confusing to add this another different "offload". That's
> just confusing.
>
> I still like "switch" the best. If it passes packets around, it's a
> "switch", +-. Everybody understand what's going on if you use "switch".
> If you use "offload", everybody is confused...
>
Those are all *legitimate offloads* ;->
The macvlan one looks a little creepy. Perhaps we could eventually
merge all that stuff together with this effort.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 08/17] bridge: call netdev_sw_port_stp_update when bridge port STP status changes
From: Jamal Hadi Salim @ 2014-11-28 13:17 UTC (permalink / raw)
To: Scott Feldman, Roopa Prabhu
Cc: Jiri Pirko, Netdev, David S. Miller, nhorman@tuxdriver.com,
Andy Gospodarek, Thomas Graf, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Florian Fainelli, John Linville,
jasowang@redhat.com
In-Reply-To: <CAE4R7bCfi-90pccDJN350bdeQi2R4H5Xbu3-BADZ29vWhfkJiA@mail.gmail.com>
On 11/28/14 05:51, Scott Feldman wrote:
> On Fri, Nov 28, 2014 at 2:05 AM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>> On 11/25/14, 5:35 PM, Scott Feldman wrote:
>>>
>>> The
>>> bridge driver or external STP process (msptd) is still controlling STP
>>> state for the port and processing the BPDUs. When the state changes
>>> on the port, the bridge driver is letting HW know, that's it.
>>
>>
>> I understand that. In which case, we should not call it stp state.
>> It is just port state.
>
> Sure, call it port state but it takes on BR_STATE_xxx values which
> just so happen to correspond exactly to STP states.
>
>> And since it is yet another port attribute like port
>> priority,
>> we should be able to use the same api to offload it to hw just like the
>> other port attributes.
>
> Well it does...see ndo_bridge_setlink in bridge driver, br_setport
> where IFLA_BRPORT_STATE is handled...it calls br_set_port_state(),
> which calls into the swdev port driver. That's for the case where
> user or external processing is setting STP state. For the case where
> the bridge itself is managing the STP state, the bridge will make the
> same br_set_port_state() call to adjust the port state.
>
What Roopa is requesting for if i am not mistaken is the same issue i
raised earlier as well. We need an opaque way to set and get these
attributes. We cant afford an ndo ops per bridge or the next thing.
Its a port level issue - what it is depends on what the underlying
hardware does.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 08/17] bridge: call netdev_sw_port_stp_update when bridge port STP status changes
From: Jiri Pirko @ 2014-11-28 13:27 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Scott Feldman, Roopa Prabhu, Netdev, David S. Miller,
nhorman@tuxdriver.com, Andy Gospodarek, Thomas Graf,
dborkman@redhat.com, ogerlitz@mellanox.com, jesse@nicira.com,
pshelar@nicira.com, azhou@nicira.com, ben@decadent.org.uk,
stephen@networkplumber.org, Kirsher, Jeffrey T,
vyasevic@redhat.com, Cong Wang, Fastabend, John R, Eric Dumazet,
Florian Fainelli, John Linville
In-Reply-To: <547875F1.9080204@mojatatu.com>
Fri, Nov 28, 2014 at 02:17:37PM CET, jhs@mojatatu.com wrote:
>On 11/28/14 05:51, Scott Feldman wrote:
>>On Fri, Nov 28, 2014 at 2:05 AM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>>>On 11/25/14, 5:35 PM, Scott Feldman wrote:
>>>>
>>>> The
>>>>bridge driver or external STP process (msptd) is still controlling STP
>>>>state for the port and processing the BPDUs. When the state changes
>>>>on the port, the bridge driver is letting HW know, that's it.
>>>
>>>
>>>I understand that. In which case, we should not call it stp state.
>>>It is just port state.
>>
>>Sure, call it port state but it takes on BR_STATE_xxx values which
>>just so happen to correspond exactly to STP states.
>>
>>>And since it is yet another port attribute like port
>>>priority,
>>>we should be able to use the same api to offload it to hw just like the
>>>other port attributes.
>>
>>Well it does...see ndo_bridge_setlink in bridge driver, br_setport
>>where IFLA_BRPORT_STATE is handled...it calls br_set_port_state(),
>>which calls into the swdev port driver. That's for the case where
>>user or external processing is setting STP state. For the case where
>>the bridge itself is managing the STP state, the bridge will make the
>>same br_set_port_state() call to adjust the port state.
>>
>
>What Roopa is requesting for if i am not mistaken is the same issue i
>raised earlier as well. We need an opaque way to set and get these
>attributes. We cant afford an ndo ops per bridge or the next thing.
>Its a port level issue - what it is depends on what the underlying
>hardware does.
I agree. This will be addressed (it's in the etherpad todo).
>
>cheers,
>jamal
>
^ permalink raw reply
* [patch net-next v5 00/21] introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload
From: Jiri Pirko @ 2014-11-28 13:34 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
Hi all.
This patchset is just the first phase of switch and switch-ish device
support api in kernel. Note that the api will extend.
So what this patchset includes:
- introduce switchdev api skeleton for implementing switch drivers
- introduce rocker switch driver which implements switchdev api fdb and
bridge set/get link ndos
As to the discussion if there is need to have specific class of device
representing the switch itself, so far we found no need to introduce that.
But we are generally ok with the idea and when the time comes and it will
be needed, it can be easily introduced without any disturbance.
This patchset introduces switch id export through rtnetlink and sysfs,
which is similar to what we have for port id in SR-IOV. I will send iproute2
patchset for showing the switch id for port netdevs once this is applied.
This applies also for the PF_BRIDGE and fdb iproute2 patches.
iproute2 patches are now available here:
https://github.com/jpirko/iproute2-rocker
For detailed description and version history, please see individual patches.
In v4 I reordered the patches leaving rocker patches on the end of the patchset.
In v5 I only fixed whitespace issues of patch #13
We have a TODO for related items we want to work on in near future:
https://etherpad.wikimedia.org/p/netdev-swdev-todo
Jiri Pirko (10):
bridge: rename fdb_*_hw to fdb_*_hw_addr to avoid confusion
neigh: sort Neighbor Cache Entry Flags
bridge: convert flags in fbd entry into bitfields
net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
net: rename netdev_phys_port_id to more generic name
net: introduce generic switch devices support
rtnl: expose physical switch id for particular device
net-sysfs: expose physical switch id for particular device
rocker: introduce rocker switch driver
rocker: implement ndo_fdb_dump
Scott Feldman (9):
bridge: call netdev_sw_port_stp_update when bridge port STP status
changes
bridge: add API to notify bridge driver of learned FBD on offloaded
device
bridge: move private brport flags to if_bridge.h so port drivers can
use flags
bridge: add new brport flag LEARNING_SYNC
bridge: add new hwmode swdev
bridge: add brport flags to dflt bridge_getlink
rocker: implement rocker ofdpa flow table manipulation
rocker: implement L2 bridge offloading
rocker: add ndo_bridge_setlink/getlink support for learning policy
Thomas Graf (2):
rocker: Add proper validation of Netlink attributes
rocker: Use logical operators on booleans
Documentation/ABI/testing/sysfs-class-net | 8 +
Documentation/networking/switchdev.txt | 59 +
MAINTAINERS | 14 +
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/Makefile | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
drivers/net/ethernet/emulex/benet/be_main.c | 3 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 4 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +-
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 11 +-
drivers/net/ethernet/rocker/Kconfig | 27 +
drivers/net/ethernet/rocker/Makefile | 5 +
drivers/net/ethernet/rocker/rocker.c | 4374 ++++++++++++++++++++++
drivers/net/ethernet/rocker/rocker.h | 428 +++
drivers/net/macvlan.c | 4 +-
drivers/net/vxlan.c | 4 +-
include/linux/if_bridge.h | 31 +
include/linux/netdevice.h | 39 +-
include/linux/rtnetlink.h | 9 +-
include/net/switchdev.h | 37 +
include/uapi/linux/if_bridge.h | 1 +
include/uapi/linux/if_link.h | 2 +
include/uapi/linux/neighbour.h | 6 +-
net/Kconfig | 1 +
net/Makefile | 3 +
net/bridge/br_fdb.c | 144 +-
net/bridge/br_private.h | 21 +-
net/bridge/br_stp.c | 7 +
net/core/dev.c | 2 +-
net/core/net-sysfs.c | 26 +-
net/core/rtnetlink.c | 119 +-
net/switchdev/Kconfig | 13 +
net/switchdev/Makefile | 5 +
net/switchdev/switchdev.c | 52 +
35 files changed, 5366 insertions(+), 105 deletions(-)
create mode 100644 Documentation/networking/switchdev.txt
create mode 100644 drivers/net/ethernet/rocker/Kconfig
create mode 100644 drivers/net/ethernet/rocker/Makefile
create mode 100644 drivers/net/ethernet/rocker/rocker.c
create mode 100644 drivers/net/ethernet/rocker/rocker.h
create mode 100644 include/net/switchdev.h
create mode 100644 net/switchdev/Kconfig
create mode 100644 net/switchdev/Makefile
create mode 100644 net/switchdev/switchdev.c
--
1.9.3
^ permalink raw reply
* [patch net-next v5 01/21] bridge: rename fdb_*_hw to fdb_*_hw_addr to avoid confusion
From: Jiri Pirko @ 2014-11-28 13:34 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417181672-11531-1-git-send-email-jiri@resnulli.us>
The current name might seem that this actually offloads the fdb entry to
hw. So rename it to clearly present that this for hardware address
addition/removal.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Andy Gospodarek <gospo@cumulusnetworks.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
v3->v4->v5:
-no change
v2->v3:
-moved the patch to the patchset head
new in v2 as suggested by DaveM
---
net/bridge/br_fdb.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 6f6c95c..08ef4e7 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -90,7 +90,7 @@ static void fdb_rcu_free(struct rcu_head *head)
* are then updated with the new information.
* Called under RTNL.
*/
-static void fdb_add_hw(struct net_bridge *br, const unsigned char *addr)
+static void fdb_add_hw_addr(struct net_bridge *br, const unsigned char *addr)
{
int err;
struct net_bridge_port *p;
@@ -118,7 +118,7 @@ undo:
* the ports with needed information.
* Called under RTNL.
*/
-static void fdb_del_hw(struct net_bridge *br, const unsigned char *addr)
+static void fdb_del_hw_addr(struct net_bridge *br, const unsigned char *addr)
{
struct net_bridge_port *p;
@@ -133,7 +133,7 @@ static void fdb_del_hw(struct net_bridge *br, const unsigned char *addr)
static void fdb_delete(struct net_bridge *br, struct net_bridge_fdb_entry *f)
{
if (f->is_static)
- fdb_del_hw(br, f->addr.addr);
+ fdb_del_hw_addr(br, f->addr.addr);
hlist_del_rcu(&f->hlist);
fdb_notify(br, f, RTM_DELNEIGH);
@@ -514,7 +514,7 @@ static int fdb_insert(struct net_bridge *br, struct net_bridge_port *source,
return -ENOMEM;
fdb->is_local = fdb->is_static = 1;
- fdb_add_hw(br, addr);
+ fdb_add_hw_addr(br, addr);
fdb_notify(br, fdb, RTM_NEWNEIGH);
return 0;
}
@@ -754,19 +754,19 @@ static int fdb_add_entry(struct net_bridge_port *source, const __u8 *addr,
fdb->is_local = 1;
if (!fdb->is_static) {
fdb->is_static = 1;
- fdb_add_hw(br, addr);
+ fdb_add_hw_addr(br, addr);
}
} else if (state & NUD_NOARP) {
fdb->is_local = 0;
if (!fdb->is_static) {
fdb->is_static = 1;
- fdb_add_hw(br, addr);
+ fdb_add_hw_addr(br, addr);
}
} else {
fdb->is_local = 0;
if (fdb->is_static) {
fdb->is_static = 0;
- fdb_del_hw(br, addr);
+ fdb_del_hw_addr(br, addr);
}
}
--
1.9.3
^ permalink raw reply related
* [patch net-next v5 02/21] neigh: sort Neighbor Cache Entry Flags
From: Jiri Pirko @ 2014-11-28 13:34 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417181672-11531-1-git-send-email-jiri@resnulli.us>
Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
v4->v5:
-no change
new in v4
---
include/uapi/linux/neighbour.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/neighbour.h b/include/uapi/linux/neighbour.h
index 4a1d7e9..2f043af 100644
--- a/include/uapi/linux/neighbour.h
+++ b/include/uapi/linux/neighbour.h
@@ -35,11 +35,10 @@ enum {
*/
#define NTF_USE 0x01
-#define NTF_PROXY 0x08 /* == ATF_PUBL */
-#define NTF_ROUTER 0x80
-
#define NTF_SELF 0x02
#define NTF_MASTER 0x04
+#define NTF_PROXY 0x08 /* == ATF_PUBL */
+#define NTF_ROUTER 0x80
/*
* Neighbor Cache Entry States.
--
1.9.3
^ permalink raw reply related
* [patch net-next v5 03/21] bridge: convert flags in fbd entry into bitfields
From: Jiri Pirko @ 2014-11-28 13:34 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417181672-11531-1-git-send-email-jiri@resnulli.us>
Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
v4->v5:
-no change
new in v4
---
net/bridge/br_private.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 8f3f081..5b37077 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -98,9 +98,9 @@ struct net_bridge_fdb_entry
unsigned long updated;
unsigned long used;
mac_addr addr;
- unsigned char is_local;
- unsigned char is_static;
- unsigned char added_by_user;
+ unsigned char is_local:1,
+ is_static:1,
+ added_by_user:1;
__u16 vlan_id;
};
--
1.9.3
^ permalink raw reply related
* [patch net-next v5 04/21] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Jiri Pirko @ 2014-11-28 13:34 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417181672-11531-1-git-send-email-jiri@resnulli.us>
Do the work of parsing NDA_VLAN directly in rtnetlink code, pass simple
u16 vid to drivers from there.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Andy Gospodarek <gospo@cumulusnetworks.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
---
v4->v5:
-no change
v3->v4:
-fixed spelling of "fdb" pointed out by Andy
new in v3
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 9 +++--
drivers/net/macvlan.c | 4 +-
drivers/net/vxlan.c | 4 +-
include/linux/netdevice.h | 8 ++--
include/linux/rtnetlink.h | 6 ++-
net/bridge/br_fdb.c | 39 ++----------------
net/bridge/br_private.h | 4 +-
net/core/rtnetlink.c | 50 ++++++++++++++++++++----
10 files changed, 70 insertions(+), 60 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 7262077..5ed5e40 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -7536,7 +7536,7 @@ static int i40e_get_phys_port_id(struct net_device *netdev,
*/
static int i40e_ndo_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
struct net_device *dev,
- const unsigned char *addr,
+ const unsigned char *addr, u16 vid,
u16 flags)
{
struct i40e_netdev_priv *np = netdev_priv(dev);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 932f779..1bad9f4 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7708,7 +7708,7 @@ static int ixgbe_set_features(struct net_device *netdev,
static int ixgbe_ndo_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
struct net_device *dev,
- const unsigned char *addr,
+ const unsigned char *addr, u16 vid,
u16 flags)
{
/* guarantee we can provide a unique filter for the unicast address */
@@ -7717,7 +7717,7 @@ static int ixgbe_ndo_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
return -ENOMEM;
}
- return ndo_dflt_fdb_add(ndm, tb, dev, addr, flags);
+ return ndo_dflt_fdb_add(ndm, tb, dev, addr, vid, flags);
}
static int ixgbe_ndo_bridge_setlink(struct net_device *dev,
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index a913b3a..3227c80 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -376,13 +376,14 @@ static int qlcnic_set_mac(struct net_device *netdev, void *p)
}
static int qlcnic_fdb_del(struct ndmsg *ndm, struct nlattr *tb[],
- struct net_device *netdev, const unsigned char *addr)
+ struct net_device *netdev,
+ const unsigned char *addr, u16 vid)
{
struct qlcnic_adapter *adapter = netdev_priv(netdev);
int err = -EOPNOTSUPP;
if (!adapter->fdb_mac_learn)
- return ndo_dflt_fdb_del(ndm, tb, netdev, addr);
+ return ndo_dflt_fdb_del(ndm, tb, netdev, addr, vid);
if ((adapter->flags & QLCNIC_ESWITCH_ENABLED) ||
qlcnic_sriov_check(adapter)) {
@@ -401,13 +402,13 @@ static int qlcnic_fdb_del(struct ndmsg *ndm, struct nlattr *tb[],
static int qlcnic_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
struct net_device *netdev,
- const unsigned char *addr, u16 flags)
+ const unsigned char *addr, u16 vid, u16 flags)
{
struct qlcnic_adapter *adapter = netdev_priv(netdev);
int err = 0;
if (!adapter->fdb_mac_learn)
- return ndo_dflt_fdb_add(ndm, tb, netdev, addr, flags);
+ return ndo_dflt_fdb_add(ndm, tb, netdev, addr, vid, flags);
if (!(adapter->flags & QLCNIC_ESWITCH_ENABLED) &&
!qlcnic_sriov_check(adapter)) {
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index bfb0b6e..a1a3e3e 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -872,7 +872,7 @@ static int macvlan_vlan_rx_kill_vid(struct net_device *dev,
static int macvlan_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
struct net_device *dev,
- const unsigned char *addr,
+ const unsigned char *addr, u16 vid,
u16 flags)
{
struct macvlan_dev *vlan = netdev_priv(dev);
@@ -897,7 +897,7 @@ static int macvlan_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
static int macvlan_fdb_del(struct ndmsg *ndm, struct nlattr *tb[],
struct net_device *dev,
- const unsigned char *addr)
+ const unsigned char *addr, u16 vid)
{
struct macvlan_dev *vlan = netdev_priv(dev);
int err = -EINVAL;
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index e9f81d4..7d8013d 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -849,7 +849,7 @@ static int vxlan_fdb_parse(struct nlattr *tb[], struct vxlan_dev *vxlan,
/* Add static entry (via netlink) */
static int vxlan_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
struct net_device *dev,
- const unsigned char *addr, u16 flags)
+ const unsigned char *addr, u16 vid, u16 flags)
{
struct vxlan_dev *vxlan = netdev_priv(dev);
/* struct net *net = dev_net(vxlan->dev); */
@@ -885,7 +885,7 @@ static int vxlan_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
/* Delete entry (via netlink) */
static int vxlan_fdb_delete(struct ndmsg *ndm, struct nlattr *tb[],
struct net_device *dev,
- const unsigned char *addr)
+ const unsigned char *addr, u16 vid)
{
struct vxlan_dev *vxlan = netdev_priv(dev);
struct vxlan_fdb *f;
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 2cb7724..589929c 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -951,11 +951,11 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
*
* int (*ndo_fdb_add)(struct ndmsg *ndm, struct nlattr *tb[],
* struct net_device *dev,
- * const unsigned char *addr, u16 flags)
+ * const unsigned char *addr, u16 vid, u16 flags)
* Adds an FDB entry to dev for addr.
* int (*ndo_fdb_del)(struct ndmsg *ndm, struct nlattr *tb[],
* struct net_device *dev,
- * const unsigned char *addr)
+ * const unsigned char *addr, u16 vid)
* Deletes the FDB entry from dev coresponding to addr.
* int (*ndo_fdb_dump)(struct sk_buff *skb, struct netlink_callback *cb,
* struct net_device *dev, struct net_device *filter_dev,
@@ -1128,11 +1128,13 @@ struct net_device_ops {
struct nlattr *tb[],
struct net_device *dev,
const unsigned char *addr,
+ u16 vid,
u16 flags);
int (*ndo_fdb_del)(struct ndmsg *ndm,
struct nlattr *tb[],
struct net_device *dev,
- const unsigned char *addr);
+ const unsigned char *addr,
+ u16 vid);
int (*ndo_fdb_dump)(struct sk_buff *skb,
struct netlink_callback *cb,
struct net_device *dev,
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index 6cacbce..063f0f5 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -94,11 +94,13 @@ extern int ndo_dflt_fdb_add(struct ndmsg *ndm,
struct nlattr *tb[],
struct net_device *dev,
const unsigned char *addr,
- u16 flags);
+ u16 vid,
+ u16 flags);
extern int ndo_dflt_fdb_del(struct ndmsg *ndm,
struct nlattr *tb[],
struct net_device *dev,
- const unsigned char *addr);
+ const unsigned char *addr,
+ u16 vid);
extern int ndo_dflt_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
struct net_device *dev, u16 mode);
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 08ef4e7..b1be971 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -805,33 +805,17 @@ static int __br_fdb_add(struct ndmsg *ndm, struct net_bridge_port *p,
/* Add new permanent fdb entry with RTM_NEWNEIGH */
int br_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
struct net_device *dev,
- const unsigned char *addr, u16 nlh_flags)
+ const unsigned char *addr, u16 vid, u16 nlh_flags)
{
struct net_bridge_port *p;
int err = 0;
struct net_port_vlans *pv;
- unsigned short vid = VLAN_N_VID;
if (!(ndm->ndm_state & (NUD_PERMANENT|NUD_NOARP|NUD_REACHABLE))) {
pr_info("bridge: RTM_NEWNEIGH with invalid state %#x\n", ndm->ndm_state);
return -EINVAL;
}
- if (tb[NDA_VLAN]) {
- if (nla_len(tb[NDA_VLAN]) != sizeof(unsigned short)) {
- pr_info("bridge: RTM_NEWNEIGH with invalid vlan\n");
- return -EINVAL;
- }
-
- vid = nla_get_u16(tb[NDA_VLAN]);
-
- if (!vid || vid >= VLAN_VID_MASK) {
- pr_info("bridge: RTM_NEWNEIGH with invalid vlan id %d\n",
- vid);
- return -EINVAL;
- }
- }
-
if (is_zero_ether_addr(addr)) {
pr_info("bridge: RTM_NEWNEIGH with invalid ether address\n");
return -EINVAL;
@@ -845,7 +829,7 @@ int br_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
}
pv = nbp_get_vlan_info(p);
- if (vid != VLAN_N_VID) {
+ if (vid) {
if (!pv || !test_bit(vid, pv->vlan_bitmap)) {
pr_info("bridge: RTM_NEWNEIGH with unconfigured "
"vlan %d on port %s\n", vid, dev->name);
@@ -903,27 +887,12 @@ static int __br_fdb_delete(struct net_bridge_port *p,
/* Remove neighbor entry with RTM_DELNEIGH */
int br_fdb_delete(struct ndmsg *ndm, struct nlattr *tb[],
struct net_device *dev,
- const unsigned char *addr)
+ const unsigned char *addr, u16 vid)
{
struct net_bridge_port *p;
int err;
struct net_port_vlans *pv;
- unsigned short vid = VLAN_N_VID;
-
- if (tb[NDA_VLAN]) {
- if (nla_len(tb[NDA_VLAN]) != sizeof(unsigned short)) {
- pr_info("bridge: RTM_NEWNEIGH with invalid vlan\n");
- return -EINVAL;
- }
- vid = nla_get_u16(tb[NDA_VLAN]);
-
- if (!vid || vid >= VLAN_VID_MASK) {
- pr_info("bridge: RTM_NEWNEIGH with invalid vlan id %d\n",
- vid);
- return -EINVAL;
- }
- }
p = br_port_get_rtnl(dev);
if (p == NULL) {
pr_info("bridge: RTM_DELNEIGH %s not a bridge port\n",
@@ -932,7 +901,7 @@ int br_fdb_delete(struct ndmsg *ndm, struct nlattr *tb[],
}
pv = nbp_get_vlan_info(p);
- if (vid != VLAN_N_VID) {
+ if (vid) {
if (!pv || !test_bit(vid, pv->vlan_bitmap)) {
pr_info("bridge: RTM_DELNEIGH with unconfigured "
"vlan %d on port %s\n", vid, dev->name);
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 5b37077..1b529da 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -404,9 +404,9 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source,
const unsigned char *addr, u16 vid, bool added_by_user);
int br_fdb_delete(struct ndmsg *ndm, struct nlattr *tb[],
- struct net_device *dev, const unsigned char *addr);
+ struct net_device *dev, const unsigned char *addr, u16 vid);
int br_fdb_add(struct ndmsg *nlh, struct nlattr *tb[], struct net_device *dev,
- const unsigned char *addr, u16 nlh_flags);
+ const unsigned char *addr, u16 vid, u16 nlh_flags);
int br_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb,
struct net_device *dev, struct net_device *fdev, int idx);
int br_fdb_sync_static(struct net_bridge *br, struct net_bridge_port *p);
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index a688268..85d1d76 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -36,6 +36,7 @@
#include <linux/mutex.h>
#include <linux/if_addr.h>
#include <linux/if_bridge.h>
+#include <linux/if_vlan.h>
#include <linux/pci.h>
#include <linux/etherdevice.h>
@@ -2312,7 +2313,7 @@ errout:
int ndo_dflt_fdb_add(struct ndmsg *ndm,
struct nlattr *tb[],
struct net_device *dev,
- const unsigned char *addr,
+ const unsigned char *addr, u16 vid,
u16 flags)
{
int err = -EINVAL;
@@ -2338,6 +2339,28 @@ int ndo_dflt_fdb_add(struct ndmsg *ndm,
}
EXPORT_SYMBOL(ndo_dflt_fdb_add);
+static int fdb_vid_parse(struct nlattr *vlan_attr, u16 *p_vid)
+{
+ u16 vid = 0;
+
+ if (vlan_attr) {
+ if (nla_len(vlan_attr) != sizeof(u16)) {
+ pr_info("PF_BRIDGE: RTM_NEWNEIGH with invalid vlan\n");
+ return -EINVAL;
+ }
+
+ vid = nla_get_u16(vlan_attr);
+
+ if (!vid || vid >= VLAN_VID_MASK) {
+ pr_info("PF_BRIDGE: RTM_NEWNEIGH with invalid vlan id %d\n",
+ vid);
+ return -EINVAL;
+ }
+ }
+ *p_vid = vid;
+ return 0;
+}
+
static int rtnl_fdb_add(struct sk_buff *skb, struct nlmsghdr *nlh)
{
struct net *net = sock_net(skb->sk);
@@ -2345,6 +2368,7 @@ static int rtnl_fdb_add(struct sk_buff *skb, struct nlmsghdr *nlh)
struct nlattr *tb[NDA_MAX+1];
struct net_device *dev;
u8 *addr;
+ u16 vid;
int err;
err = nlmsg_parse(nlh, sizeof(*ndm), tb, NDA_MAX, NULL);
@@ -2370,6 +2394,10 @@ static int rtnl_fdb_add(struct sk_buff *skb, struct nlmsghdr *nlh)
addr = nla_data(tb[NDA_LLADDR]);
+ err = fdb_vid_parse(tb[NDA_VLAN], &vid);
+ if (err)
+ return err;
+
err = -EOPNOTSUPP;
/* Support fdb on master device the net/bridge default case */
@@ -2378,7 +2406,8 @@ static int rtnl_fdb_add(struct sk_buff *skb, struct nlmsghdr *nlh)
struct net_device *br_dev = netdev_master_upper_dev_get(dev);
const struct net_device_ops *ops = br_dev->netdev_ops;
- err = ops->ndo_fdb_add(ndm, tb, dev, addr, nlh->nlmsg_flags);
+ err = ops->ndo_fdb_add(ndm, tb, dev, addr, vid,
+ nlh->nlmsg_flags);
if (err)
goto out;
else
@@ -2389,9 +2418,10 @@ static int rtnl_fdb_add(struct sk_buff *skb, struct nlmsghdr *nlh)
if ((ndm->ndm_flags & NTF_SELF)) {
if (dev->netdev_ops->ndo_fdb_add)
err = dev->netdev_ops->ndo_fdb_add(ndm, tb, dev, addr,
+ vid,
nlh->nlmsg_flags);
else
- err = ndo_dflt_fdb_add(ndm, tb, dev, addr,
+ err = ndo_dflt_fdb_add(ndm, tb, dev, addr, vid,
nlh->nlmsg_flags);
if (!err) {
@@ -2409,7 +2439,7 @@ out:
int ndo_dflt_fdb_del(struct ndmsg *ndm,
struct nlattr *tb[],
struct net_device *dev,
- const unsigned char *addr)
+ const unsigned char *addr, u16 vid)
{
int err = -EINVAL;
@@ -2438,6 +2468,7 @@ static int rtnl_fdb_del(struct sk_buff *skb, struct nlmsghdr *nlh)
struct net_device *dev;
int err = -EINVAL;
__u8 *addr;
+ u16 vid;
if (!netlink_capable(skb, CAP_NET_ADMIN))
return -EPERM;
@@ -2465,6 +2496,10 @@ static int rtnl_fdb_del(struct sk_buff *skb, struct nlmsghdr *nlh)
addr = nla_data(tb[NDA_LLADDR]);
+ err = fdb_vid_parse(tb[NDA_VLAN], &vid);
+ if (err)
+ return err;
+
err = -EOPNOTSUPP;
/* Support fdb on master device the net/bridge default case */
@@ -2474,7 +2509,7 @@ static int rtnl_fdb_del(struct sk_buff *skb, struct nlmsghdr *nlh)
const struct net_device_ops *ops = br_dev->netdev_ops;
if (ops->ndo_fdb_del)
- err = ops->ndo_fdb_del(ndm, tb, dev, addr);
+ err = ops->ndo_fdb_del(ndm, tb, dev, addr, vid);
if (err)
goto out;
@@ -2485,9 +2520,10 @@ static int rtnl_fdb_del(struct sk_buff *skb, struct nlmsghdr *nlh)
/* Embedded bridge, macvlan, and any other device support */
if (ndm->ndm_flags & NTF_SELF) {
if (dev->netdev_ops->ndo_fdb_del)
- err = dev->netdev_ops->ndo_fdb_del(ndm, tb, dev, addr);
+ err = dev->netdev_ops->ndo_fdb_del(ndm, tb, dev, addr,
+ vid);
else
- err = ndo_dflt_fdb_del(ndm, tb, dev, addr);
+ err = ndo_dflt_fdb_del(ndm, tb, dev, addr, vid);
if (!err) {
rtnl_fdb_notify(dev, addr, RTM_DELNEIGH);
--
1.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox