* Re: [PATCH 1/1] net: cassini: Deletion of an unnecessary check before the function call "vfree"
From: David Miller @ 2014-12-06 5:14 UTC (permalink / raw)
To: elfring; +Cc: netdev, linux-kernel, kernel-janitors, cocci
In-Reply-To: <5479D2AD.9060704@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 29 Nov 2014 15:05:33 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 29 Nov 2014 14:34:59 +0100
>
> The vfree() function performs also input parameter validation.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] net-PA Semi: Deletion of unnecessary checks before the function call "pci_dev_put"
From: David Miller @ 2014-12-06 5:15 UTC (permalink / raw)
To: elfring; +Cc: olof, netdev, linux-kernel, kernel-janitors, julia.lawall
In-Reply-To: <547A09B1.9090102@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 29 Nov 2014 19:00:17 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 29 Nov 2014 18:55:40 +0100
>
> The pci_dev_put() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call
> is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net] bpf: x86: fix epilogue generation for eBPF programs
From: David Miller @ 2014-12-06 5:24 UTC (permalink / raw)
To: ast; +Cc: zlim.lnx, edumazet, dborkman, hpa, tglx, mingo, netdev,
linux-kernel
In-Reply-To: <1417301173-23691-1-git-send-email-ast@plumgrid.com>
From: Alexei Starovoitov <ast@plumgrid.com>
Date: Sat, 29 Nov 2014 14:46:13 -0800
> 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.
>
> Since jump offset to epilogue is computed as:
> jmp_offset = ctx->cleanup_addr - addrs[i]
> we need to change type of cleanup_addr to signed to compute the offset as:
> (long long) ((int)20 - (int)30)
> instead of:
> (long long) ((unsigned int)20 - (int)30)
>
> Fixes: 622582786c9e ("net: filter: x86: internal BPF JIT")
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: David Miller @ 2014-12-06 5:31 UTC (permalink / raw)
To: weiyang; +Cc: netdev, gideonn, edumazet, amirv
In-Reply-To: <1417315431-16761-1-git-send-email-weiyang@linux.vnet.ibm.com>
From: Wei Yang <weiyang@linux.vnet.ibm.com>
Date: Sun, 30 Nov 2014 10:43:51 +0800
> In commit 6a4e812 (net/mlx4_en: Avoid calling bswap in tx fast path), we store
> doorbell_qpn in big endian to avoid bswap(). Then we try to write it directly
> by iowrite32() instead of iowrite32be().
>
> This works fine on little endian platform, while has some problem on big
> endian platform. Here is the definition in general:
>
> #define iowrite32(v, addr) writel((v), (addr))
> #define writel(b,addr) __raw_writel(__cpu_to_le32(b),addr)
>
> On little endian platform, the value is not swapped before write. While on big
> endian platform, the value is swapped. This is not expected to happen.
>
> This patch does the swap on big endian platform before it is written.
>
> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Guys, let's figure out what we are doing with this patch.
^ permalink raw reply
* Re: [PATCH] pxa168: close race between napi and irq activation
From: David Miller @ 2014-12-06 5:34 UTC (permalink / raw)
To: LinoSanfilippo
Cc: arnd, paul.gortmaker, w-lkml, f.fainelli, netdev, linux-kernel
In-Reply-To: <1417344576-4940-1-git-send-email-LinoSanfilippo@gmx.de>
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Date: Sun, 30 Nov 2014 11:49:36 +0100
> In pxa168_eth_open() the irqs are enabled before napi. This opens a tiny time
> window in which the irq handler is processed, disables irqs but then is not able
> to schedule the not yet activated napi, leaving irqs disabled forever (since
> irqs are reenabled in napi poll function).
> Fix this race by activating napi before irqs are activated.
>
> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH] skge: Unmask interrupts in case of spurious interrupts
From: David Miller @ 2014-12-06 5:34 UTC (permalink / raw)
To: LinoSanfilippo; +Cc: stephen, mlindner, netdev, linux-kernel
In-Reply-To: <1417348291-1302-1-git-send-email-LinoSanfilippo@gmx.de>
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Date: Sun, 30 Nov 2014 12:51:31 +0100
> In case of a spurious interrupt dont forget to reenable the interrupts that
> have been masked by reading the interrupt source register.
>
> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH] sky2: avoid pci write posting after disabling irqs
From: David Miller @ 2014-12-06 5:34 UTC (permalink / raw)
To: LinoSanfilippo; +Cc: stephen, mlindner, netdev, linux-kernel
In-Reply-To: <1417348611-1752-1-git-send-email-LinoSanfilippo@gmx.de>
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Date: Sun, 30 Nov 2014 12:56:51 +0100
> In sky2_change_mtu setting B0_IMSK to 0 may be delayed due to PCI write posting
> which could result in irqs being still active when synchronize_irq is called.
> Since we are not prepared to handle any further irqs after synchronize_irq
> (our resources are freed after that) force the write by a consecutive read from
> the same register.
> Similar situation in sky2_all_down: Here we disabled irqs by a write to B0_IMSK
> but did not ensure that this write took place before synchronize_irq. Fix that
> too.
>
> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH] uapi: fix to export linux/vm_sockets.h
From: David Miller @ 2014-12-06 5:36 UTC (permalink / raw)
To: yamada.m-NAum8xwdG0+S7A1Ibl2khg
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
ast-uqk4Ao+rVK5Wk0Htik3J/w, piotr.krol-zILERgsGILsAvxtiuMwx3w,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1417396577-32499-1-git-send-email-yamada.m-NAum8xwdG0+S7A1Ibl2khg@public.gmane.org>
From: Masahiro Yamada <yamada.m-NAum8xwdG0+S7A1Ibl2khg@public.gmane.org>
Date: Mon, 1 Dec 2014 10:16:17 +0900
> A typo "header=y" was introduced by commit 7071cf7fc435
> (uapi: add missing network related headers to kbuild).
>
> Signed-off-by: Masahiro Yamada <yamada.m-NAum8xwdG0+S7A1Ibl2khg@public.gmane.org>
> Cc: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH v2 iproute] bridge link: add option 'self'
From: Scott Feldman @ 2014-12-06 5:36 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller, shm,
Andy Gospodarek
In-Reply-To: <1417827563-811-1-git-send-email-roopa@cumulusnetworks.com>
On Fri, Dec 5, 2014 at 4:59 PM, <roopa@cumulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> Currently self is set internally only if hwmode is set.
> This makes it necessary for the hw to have a mode.
> There is no hwmode really required to go to hardware. So, introduce
> self for anybody who wants to target hardware.
>
> v1 -> v2
> - fix a few bugs. Initialize flags to zero: this was required to
> keep the current behaviour unchanged.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
> bridge/link.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/bridge/link.c b/bridge/link.c
> index 90d9e7f..b8b8675 100644
> --- a/bridge/link.c
> +++ b/bridge/link.c
> @@ -261,7 +261,7 @@ static int brlink_modify(int argc, char **argv)
> __s16 priority = -1;
> __s8 state = -1;
> __s16 mode = -1;
> - __u16 flags = BRIDGE_FLAGS_MASTER;
> + __u16 flags = 0;
I don't follow why this change is necessary. Seems defaulting to
MASTER unless SELF is set due to "self" or "hwmode" would be more
correct (and expected).
> struct rtattr *nest;
>
> memset(&req, 0, sizeof(req));
> @@ -321,6 +321,8 @@ static int brlink_modify(int argc, char **argv)
> "\"veb\".\n");
> exit(-1);
> }
> + } else if (strcmp(*argv, "self") == 0) {
> + flags = BRIDGE_FLAGS_SELF;
> } else {
> usage();
> }
> @@ -375,10 +377,11 @@ static int brlink_modify(int argc, char **argv)
> * devices so far. Thus we only need to include the flags attribute
> * if we are setting the hw mode.
> */
The comment above needs to be updated to reflect the new logic.
> - if (mode >= 0) {
> + if (mode >= 0 || flags > 0) {
> nest = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
>
> - addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
> + if (flags > 0)
> + addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
>
> if (mode >= 0)
> addattr16(&req.n, sizeof(req), IFLA_BRIDGE_MODE, mode);
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: [PATCH net] openvswitch: Fix flow mask validation.
From: David Miller @ 2014-12-06 5:42 UTC (permalink / raw)
To: pshelar; +Cc: netdev
In-Reply-To: <1417417457-1492-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Sun, 30 Nov 2014 23:04:17 -0800
> Following patch fixes typo in the flow validation. This prevented
> installation of ARP and IPv6 flows.
>
> Fixes: 19e7a3df72 ("openvswitch: Fix NDP flow mask validation")
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] rocker: remove swdev mode
From: Scott Feldman @ 2014-12-06 5:44 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller, shm,
Andy Gospodarek
In-Reply-To: <1417828604-42722-3-git-send-email-roopa@cumulusnetworks.com>
On Fri, Dec 5, 2014 at 5:16 PM, <roopa@cumulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This resets rocker mode to zero (vepa) during gets.
> This is because the default getlink handler that rocker
> uses today always takes a mode.
>
> Will fix that in a subsequent patch.
One patch set with that fix would be better, otherwise your patch here
will show rocker port running in VEB mode, which is wrong. Maybe
return mode=-1 for unspecified, or something like that?
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
> drivers/net/ethernet/rocker/rocker.c | 18 +-----------------
> 1 file changed, 1 insertion(+), 17 deletions(-)
>
> diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
> index fded127..391077c 100644
> --- a/drivers/net/ethernet/rocker/rocker.c
> +++ b/drivers/net/ethernet/rocker/rocker.c
> @@ -3700,27 +3700,11 @@ static int rocker_port_bridge_setlink(struct net_device *dev,
> {
> struct rocker_port *rocker_port = netdev_priv(dev);
> struct nlattr *protinfo;
> - struct nlattr *afspec;
> struct nlattr *attr;
> - u16 mode;
> int err;
>
> protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg),
> IFLA_PROTINFO);
> - afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
> -
> - if (afspec) {
> - attr = nla_find_nested(afspec, IFLA_BRIDGE_MODE);
> - if (attr) {
> - if (nla_len(attr) < sizeof(mode))
> - return -EINVAL;
> -
> - mode = nla_get_u16(attr);
> - if (mode != BRIDGE_MODE_SWDEV)
> - return -EINVAL;
> - }
> - }
> -
> if (protinfo) {
> attr = nla_find_nested(protinfo, IFLA_BRPORT_LEARNING);
> if (attr) {
> @@ -3755,7 +3739,7 @@ static int rocker_port_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
> u32 filter_mask)
> {
> struct rocker_port *rocker_port = netdev_priv(dev);
> - u16 mode = BRIDGE_MODE_SWDEV;
> + u16 mode = 0;
> u32 mask = BR_LEARNING | BR_LEARNING_SYNC;
>
> return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode,
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: [PATCH V4 net-next] tun/macvtap: use consume_skb() instead of kfree_skb() when needed
From: David Miller @ 2014-12-06 5:45 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, mst, eric.dumazet
In-Reply-To: <1417423995-4765-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Mon, 1 Dec 2014 16:53:15 +0800
> To be more friendly with drop monitor, we should only call kfree_skb() when
> the packets were dropped and use consume_skb() in other cases.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: Eric Dumazet @ 2014-12-06 5:46 UTC (permalink / raw)
To: David Miller; +Cc: weiyang, netdev, gideonn, edumazet, amirv
In-Reply-To: <20141205.213112.1199355931404701216.davem@davemloft.net>
On Fri, 2014-12-05 at 21:31 -0800, David Miller wrote:
> Guys, let's figure out what we are doing with this patch.
> --
Oh well, patch is fine, please apply it, thanks !
^ permalink raw reply
* Re: [PATCH v2 net-next 0/6] allow eBPF programs to be attached to sockets
From: David Miller @ 2014-12-06 5:48 UTC (permalink / raw)
To: ast-uqk4Ao+rVK5Wk0Htik3J/w
Cc: mingo-DgEjT+Ai2ygdnm+yROfE0A, luto-kltTT9wpgjJwATOyAt5JVQ,
dborkman-H+wXaHxf7aLQT0dZR+AlfA,
hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1417475199-15950-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Date: Mon, 1 Dec 2014 15:06:33 -0800
> V1->V2:
>
> fixed comments in sample code to state clearly that packet data is accessed
> with LD_ABS instructions and not internal skb fields.
> Also replaced constants in:
> BPF_LD_ABS(BPF_B, 14 + 9 /* R0 = ip->proto */),
> with:
> BPF_LD_ABS(BPF_B, ETH_HLEN + offsetof(struct iphdr, protocol) /* R0 = ip->proto */),
>
> V1 cover:
>
> Introduce BPF_PROG_TYPE_SOCKET_FILTER type of eBPF programs that can be
> attached to sockets with setsockopt().
> Allow such programs to access maps via lookup/update/delete helpers.
>
> This feature was previewed by bpf manpage in commit b4fc1a460f30("Merge branch 'bpf-next'")
> Now it can actually run.
>
> 1st patch adds LD_ABS/LD_IND instruction verification and
> 2nd patch adds new setsockopt() flag.
> Patches 3-6 are examples in assembler and in C.
>
> Though native eBPF programs are way more powerful than classic filters
> (attachable through similar setsockopt() call), they don't have skb field
> accessors yet. Like skb->pkt_type, skb->dev->ifindex are not accessible.
> There are sevaral ways to achieve that. That will be in the next set of patches.
> So in this set native eBPF programs can only read data from packet and
> access maps.
>
> The most powerful example is sockex2_kern.c from patch 6 where ~200 lines of C
> are compiled into ~300 of eBPF instructions.
> It shows how quite complex packet parsing can be done.
>
> LLVM used to build examples is at https://github.com/iovisor/llvm
> which is fork of llvm trunk that I'm cleaning up for upstreaming.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic if feature flag set
From: Scott Feldman @ 2014-12-06 6:29 UTC (permalink / raw)
To: Arad, Ronen
Cc: Roopa Prabhu, Netdev, Jirí Pírko, Jamal Hadi Salim,
Benjamin LaHaise, Thomas Graf, john fastabend,
stephen@networkplumber.org, John Linville, nhorman@tuxdriver.com,
Nicolas Dichtel, vyasevic@redhat.com, Florian Fainelli,
buytenh@wantstofly.org, Aviad Raveh, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <E4CD12F19ABA0C4D8729E087A761DC3505D8436D@ORSMSX101.amr.corp.intel.com>
On Fri, Dec 5, 2014 at 5:04 PM, Arad, Ronen <ronen.arad@intel.com> wrote:
> I have another case of propagation which is not covered by the proposed patch.
> A recent patch introduced default_pvid attribute for a bridge (so far supported only via sysfs and not via netlink).
> When a port joins a bridge, it inherits a PVID from the default_pvid of the bridge.
> The bridge driver propagates that to the newly created net_bridge_port. This is done in br_vlan.c:
>
> int nbp_vlan_init(struct net_bridge_port *p)
> {
> int rc = 0;
>
> if (p->br->default_pvid) {
> rc = nbp_vlan_add(p, p->br->default_pvid,
> BRIDGE_VLAN_INFO_PVID |
> BRIDGE_VLAN_INFO_UNTAGGED);
> }
>
> return rc;
> }
>
> When L2 switching is offloaded to the HW, this PVID setting need to be propagated.
Agreed, it would be nice to have it propagated down, but there is a
non-ideal work-around. If you set default_pvid=0 to turn off PVID,
then the switch port driver can pick some internal VLAN ID just for HW
purposes in matching untagged pkts. It's non-ideal because the switch
port driver needs to reserve a block of VLAN IDs for internal usage or
use some other matching mechanism to keep untagged pkts within this
bridge.
Better to have default_pvid value propagated down. But, default_pvid
is a per-bridge property, not a per-bridge-port property.
RTM_SETLINK/RTM_GETLINK for PF_BRIDGE does have AFSPEC for per-bridge
and PROTINFO for per-bridge-port, so it seems PVID needs to be part of
AFSPEC.
>However, it does not come via ndo_bridge_setlink. The proposed propagation at br_setlink or an up level one at rtnetlink are not capable of handling this case.
> One possible way for handling that is to replace the call to nbp_vlan_add with a call to a new function let's say
> int br_propagate_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags)
> This function will compose a netlink message with VLAN filtering information (i.e. AF_SPEC with VLAN_INFO) and call br_setlink - leveraging the offload support proposed by Roopa.
>
> If this is an acceptable course of action, I could work on such patch.
>
>
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Arad, Ronen
>> Sent: Friday, December 05, 2014 3:21 PM
>> To: Roopa Prabhu; Scott Feldman; Netdev
>> Cc: Jirí Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
>> fastabend; stephen@networkplumber.org; John Linville;
>> nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
>> Fainelli; buytenh@wantstofly.org; Aviad Raveh; David S. Miller;
>> shm@cumulusnetworks.com; Andy Gospodarek
>> Subject: RE: [PATCH 2/3] bridge: offload bridge port attributes to switch asic
>> if feature flag set
>>
>>
>>
>> > -----Original Message-----
>> > From: netdev-owner@vger.kernel.org [mailto:netdev-
>> > owner@vger.kernel.org] On Behalf Of Roopa Prabhu
>> > Sent: Thursday, December 04, 2014 11:02 PM
>> > To: Scott Feldman
>> > Cc: Jiří Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
>> > fastabend; stephen@networkplumber.org; John Linville;
>> > nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
>> > Fainelli; buytenh@wantstofly.org; Aviad Raveh; Netdev; David S.
>> > Miller; shm@cumulusnetworks.com; Andy Gospodarek
>> > Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to
>> > switch asic if feature flag set
>> >
>> > On 12/4/14, 10:41 PM, Scott Feldman wrote:
>> > > On Thu, Dec 4, 2014 at 6:26 PM, <roopa@cumulusnetworks.com> wrote:
>> > >> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>> > >>
>> > >> This allows offloading to switch asic without having the user to
>> > >> set any flag. And this is done in the bridge driver to rollback
>> > >> kernel settings on hw offload failure if required in the future.
>> > >>
>> > >> With this, it also makes sure a notification goes out only after
>> > >> the attributes are set both in the kernel and hw.
>> > > I like this approach as it streamlines the steps for the user in
>> > > setting port flags. There is one case for FLOODING where you'll
>> > > have to turn off flooding for both, and then turn on flooding in hw.
>> > > You don't want flooding turned on on kernel and hw.
>> > ok, maybe using the higher bits as in
>> > https://patchwork.ozlabs.org/patch/413211/
>> >
>> > might help with that. Let me think some more.
>> > >
>> > >> ---
>> > >> net/bridge/br_netlink.c | 27 ++++++++++++++++++++++++++-
>> > >> 1 file changed, 26 insertions(+), 1 deletion(-)
>> > >>
>> > >> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
>> > >> index
>> > >> 9f5eb55..ce173f0 100644
>> > >> --- a/net/bridge/br_netlink.c
>> > >> +++ b/net/bridge/br_netlink.c
>> > >> @@ -407,9 +407,21 @@ int br_setlink(struct net_device *dev, struct
>> > nlmsghdr *nlh)
>> > >> afspec, RTM_SETLINK);
>> > >> }
>> > >>
>> > >> + if ((dev->features & NETIF_F_HW_SWITCH_OFFLOAD) &&
>> > >> + dev->netdev_ops->ndo_bridge_setlink) {
>> > >> + int ret = dev->netdev_ops->ndo_bridge_setlink(dev,
>> > >> + nlh);
>> > > I think you want to up-level this to net/core/rtnetlink.c because
>> > > you're only enabling the feature for one instance of a driver that
>> > > implements ndo_bridge_setlink: the bridge driver. If another driver
>> > > was MASTER and implemented ndo_bridge_setlink, you'd want same
>> check
>> > > to push setting down to SELF port driver.
>> >
>> > yeah, i thought about that. But i moved it here so that rollback would
>> > be easier.
>>
>> There is a need for propagating setlink/dellink requests down multiple levels.
>> The use-case I have in mind is a bridge at the top, team/bond in the middle,
>> and port devices at the bottom.
>> A setlink for VLAN filtering attributes would come with MASTER flag set, and
>> either port or bond/team netdev.
>> How would this be handled?
>>
>> The propagation rules between bridge and enslaved port device could be
>> different from those between bond/team and enslaved devices.
>> The current bridge driver does not propagate VLAN filtering from bridge to its
>> ports as each port could have different configuration. In a case of a
>> bond/team all members need to have the same configuration such that the a
>> bond/team would be indistinguishable from a simple port.
>>
>> Therefore rtnetlink.c might not have the knowledge for propagation across
>> multiple levels.
>> It seems that each device which implements
>> ndo_bridge_setlink/ndo_bridge_dellink and could have master role, need to
>> take care of propagation to its slaves.
>>
>> > >
>> > >> + if (ret && ret != -EOPNOTSUPP) {
>> > >> + /* XXX Fix this in the future to rollback
>> > >> + * kernel settings and return error
>> > >> + */
>> > > The future is now. Let's fix this now for the rollback case (again
>> > > up in rtnetlink.c). So then a general question comes to mind: for
>> > > these dual target sets, is it best to try HW first and then SW, or
>> > > the other way around? Either way, on failure on second you need to
>> > > rollback first. And, on failure, you need to know rollback value
>> > > for first, so you have to do a getlink on first before attempting set.
>> > yep, exactly, I went through the same thought process yesterday when i
>> > was trying to implement rollback.
>> > >
>> > >> + br_warn(p->br, "error offloading bridge attributes "
>> > >> + "on port %u(%s)\n", (unsigned int) p->port_no,
>> > >> + p->dev->name);
>> > >> + }
>> > >> + }
>> > >> +
>> > >> if (err == 0)
>> > >> br_ifinfo_notify(RTM_NEWLINK, p);
>> > >> -
>> > >> out:
>> > >> return err;
>> > >> }
>> > >> @@ -433,6 +445,19 @@ int br_dellink(struct net_device *dev, struct
>> > nlmsghdr *nlh)
>> > >> err = br_afspec((struct net_bridge *)netdev_priv(dev), p,
>> > >> afspec, RTM_DELLINK);
>> > >>
>> > >> + if (dev->features & NETIF_F_HW_SWITCH_OFFLOAD
>> > >> + && dev->netdev_ops->ndo_bridge_setlink) {
>> > >> + int ret = dev->netdev_ops->ndo_bridge_dellink(dev, nlh);
>> > >> + if (ret && ret != -EOPNOTSUPP) {
>> > >> + /* XXX Fix this in the future to rollback
>> > >> + * kernel settings and return error
>> > >> + */
>> > >> + br_warn(p->br, "error offloading bridge attributes "
>> > >> + "on port %u(%s)\n", (unsigned int) p->port_no,
>> > >> + p->dev->name);
>> > >> + }
>> > >> + }
>> > >> +
>> > > Same comments as setlink above.
>> > >
>> > >> return err;
>> > >> }
>> > >> static int br_validate(struct nlattr *tb[], struct nlattr
>> > >> *data[])
>> > >> --
>> > >> 1.7.10.4
>> > >>
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe netdev" in
>> > the body of a message to majordomo@vger.kernel.org More majordomo
>> info
>> > at http://vger.kernel.org/majordomo-info.html
>> {.n + +% lzwm b 맲 r zw u ^n r z h & G h ( 階 ݢj" m z ޖ
>> f h ~ m
^ permalink raw reply
* Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic if feature flag set
From: Scott Feldman @ 2014-12-06 6:54 UTC (permalink / raw)
To: Arad, Ronen
Cc: Roopa Prabhu, Netdev, Jirí Pírko, Jamal Hadi Salim,
Benjamin LaHaise, Thomas Graf, john fastabend,
stephen@networkplumber.org, John Linville, nhorman@tuxdriver.com,
Nicolas Dichtel, vyasevic@redhat.com, Florian Fainelli,
buytenh@wantstofly.org, Aviad Raveh, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <E4CD12F19ABA0C4D8729E087A761DC3505D842BA@ORSMSX101.amr.corp.intel.com>
On Fri, Dec 5, 2014 at 3:21 PM, Arad, Ronen <ronen.arad@intel.com> wrote:
>
>
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Roopa Prabhu
>> Sent: Thursday, December 04, 2014 11:02 PM
>> To: Scott Feldman
>> Cc: Jiří Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
>> fastabend; stephen@networkplumber.org; John Linville;
>> nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
>> Fainelli; buytenh@wantstofly.org; Aviad Raveh; Netdev; David S. Miller;
>> shm@cumulusnetworks.com; Andy Gospodarek
>> Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic
>> if feature flag set
>>
>> On 12/4/14, 10:41 PM, Scott Feldman wrote:
>> > On Thu, Dec 4, 2014 at 6:26 PM, <roopa@cumulusnetworks.com> wrote:
>> >> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>> >>
>> >> This allows offloading to switch asic without having the user to set
>> >> any flag. And this is done in the bridge driver to rollback kernel
>> >> settings on hw offload failure if required in the future.
>> >>
>> >> With this, it also makes sure a notification goes out only after the
>> >> attributes are set both in the kernel and hw.
>> > I like this approach as it streamlines the steps for the user in
>> > setting port flags. There is one case for FLOODING where you'll have
>> > to turn off flooding for both, and then turn on flooding in hw. You
>> > don't want flooding turned on on kernel and hw.
>> ok, maybe using the higher bits as in
>> https://patchwork.ozlabs.org/patch/413211/
>>
>> might help with that. Let me think some more.
>> >
>> >> ---
>> >> net/bridge/br_netlink.c | 27 ++++++++++++++++++++++++++-
>> >> 1 file changed, 26 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c index
>> >> 9f5eb55..ce173f0 100644
>> >> --- a/net/bridge/br_netlink.c
>> >> +++ b/net/bridge/br_netlink.c
>> >> @@ -407,9 +407,21 @@ int br_setlink(struct net_device *dev, struct
>> nlmsghdr *nlh)
>> >> afspec, RTM_SETLINK);
>> >> }
>> >>
>> >> + if ((dev->features & NETIF_F_HW_SWITCH_OFFLOAD) &&
>> >> + dev->netdev_ops->ndo_bridge_setlink) {
>> >> + int ret = dev->netdev_ops->ndo_bridge_setlink(dev,
>> >> + nlh);
>> > I think you want to up-level this to net/core/rtnetlink.c because
>> > you're only enabling the feature for one instance of a driver that
>> > implements ndo_bridge_setlink: the bridge driver. If another driver
>> > was MASTER and implemented ndo_bridge_setlink, you'd want same check
>> > to push setting down to SELF port driver.
>>
>> yeah, i thought about that. But i moved it here so that rollback would be
>> easier.
>
> There is a need for propagating setlink/dellink requests down multiple levels.
> The use-case I have in mind is a bridge at the top, team/bond in the middle, and port devices at the bottom.
> A setlink for VLAN filtering attributes would come with MASTER flag set, and either port or bond/team netdev.
> How would this be handled?
>
> The propagation rules between bridge and enslaved port device could be different from those between bond/team and enslaved devices.
> The current bridge driver does not propagate VLAN filtering from bridge to its ports as each port could have different configuration. In a case of a bond/team all members need to have the same configuration such that the a bond/team would be indistinguishable from a simple port.
>
> Therefore rtnetlink.c might not have the knowledge for propagation across multiple levels.
> It seems that each device which implements ndo_bridge_setlink/ndo_bridge_dellink and could have master role, need to take care of propagation to its slaves.
Thanks Ronen for bringing up this use-case of stacked masters. I
think for VLAN filtering, the stacked master case is handled, not by
ndo_setlink/dellink at each level, but with ndo_vlan_rx_kill_vid and
ndo_vlan_rx_add_vid. So the switch port driver can know VLAN
membership for port even if port is under bond which is under bridge,
by using ndo_vlan_rx_xxx and setting NETIF_F_HW_VLAN_CTAG_FILTER. The
bonding driver's ndo_vlan_rx_xxx handlers seem to keep ports in bond
VLAN membership consistent across bond.
But in general, ndo_setlink/dellink don't work for the stack use-case
for other non-VLAN attributes. Maybe the answer is to use the VLAN
propogation model for other attributes. ndo_setlink/dellink/getlink
have enough weird-isms it might be time to define cleaner ndo ops to
propagate the other attrs down.
^ permalink raw reply
* Re: [PATCH 1/3] netdev: introduce new NETIF_F_HW_SWITCH_OFFLOAD feature flag for switch device offloads
From: Roopa Prabhu @ 2014-12-06 7:46 UTC (permalink / raw)
To: Thomas Graf
Cc: jiri, sfeldma, jhs, bcrl, john.fastabend, stephen, linville,
nhorman, nicolas.dichtel, vyasevic, f.fainelli, buytenh, aviadr,
netdev, davem, shm, gospo
In-Reply-To: <20141205224320.GA22992@casper.infradead.org>
On 12/5/14, 2:43 PM, Thomas Graf wrote:
> On 12/04/14 at 06:26pm, roopa@cumulusnetworks.com wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> This is a generic high level feature flag for all switch asic features today.
>>
>> switch drivers set this flag on switch ports. Logical devices like
>> bridge, bonds, vxlans can inherit this flag from their slaves/ports.
>>
>> I had to use SWITCH in the name to avoid ambiguity with other feature
>> flags. But, since i have been harping about not calling it 'switch',
>> I am welcome to any suggestions :)
>>
>> An alternative to using a feature flag is to use a IFF_HW_OFFLOAD
>> in net_device_flags.
> What does this flag indicate specifically? What driver would
> implement ndo_bridge_setlink() but not set this flag?
>
> I think it should be clearly documented when this flag is to bet set.
I mentioned it as an alternative because it was there in my RFC patch.
There is no code for it yet.
And I will get rid of the comment in v2.
^ permalink raw reply
* Re: [PATCH v2 iproute] bridge link: add option 'self'
From: Roopa Prabhu @ 2014-12-06 8:03 UTC (permalink / raw)
To: Scott Feldman
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller, shm,
Andy Gospodarek
In-Reply-To: <CAE4R7bBYOW60bL07hD-wPWZZZxQ+jKx95cG0wnEMdU8KMZB5rw@mail.gmail.com>
On 12/5/14, 9:36 PM, Scott Feldman wrote:
> On Fri, Dec 5, 2014 at 4:59 PM, <roopa@cumulusnetworks.com> wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> Currently self is set internally only if hwmode is set.
>> This makes it necessary for the hw to have a mode.
>> There is no hwmode really required to go to hardware. So, introduce
>> self for anybody who wants to target hardware.
>>
>> v1 -> v2
>> - fix a few bugs. Initialize flags to zero: this was required to
>> keep the current behaviour unchanged.
>>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>> ---
>> bridge/link.c | 9 ++++++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/bridge/link.c b/bridge/link.c
>> index 90d9e7f..b8b8675 100644
>> --- a/bridge/link.c
>> +++ b/bridge/link.c
>> @@ -261,7 +261,7 @@ static int brlink_modify(int argc, char **argv)
>> __s16 priority = -1;
>> __s8 state = -1;
>> __s16 mode = -1;
>> - __u16 flags = BRIDGE_FLAGS_MASTER;
>> + __u16 flags = 0;
> I don't follow why this change is necessary. Seems defaulting to
> MASTER unless SELF is set due to "self" or "hwmode" would be more
> correct (and expected).
That flags initialization was always a no-op. IFLA_BRIDGE_FLAGS was
always set only with the 'self' flag on.
And i don't want to change that unnecessarily with my patch.
Setting it to master now means we will always include IFLA_AF_SPEC with
IFLA_BRIDGE_FLAGS in every 'bridge setlink' msg.
Which will be a change from the current behavior. And i dont intend to
introduce it with this patch.
Kernel has always treated no flags as 'master', so we are good from
kernel perspective.
>
>> struct rtattr *nest;
>>
>> memset(&req, 0, sizeof(req));
>> @@ -321,6 +321,8 @@ static int brlink_modify(int argc, char **argv)
>> "\"veb\".\n");
>> exit(-1);
>> }
>> + } else if (strcmp(*argv, "self") == 0) {
>> + flags = BRIDGE_FLAGS_SELF;
>> } else {
>> usage();
>> }
>> @@ -375,10 +377,11 @@ static int brlink_modify(int argc, char **argv)
>> * devices so far. Thus we only need to include the flags attribute
>> * if we are setting the hw mode.
>> */
> The comment above needs to be updated to reflect the new logic.
ok, will do, Thanks
>
>> - if (mode >= 0) {
>> + if (mode >= 0 || flags > 0) {
>> nest = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
>>
>> - addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
>> + if (flags > 0)
>> + addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
>>
>> if (mode >= 0)
>> addattr16(&req.n, sizeof(req), IFLA_BRIDGE_MODE, mode);
>> --
>> 1.7.10.4
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 2/3] bridge: offload bridge port attributes to switch asic if feature flag set
From: Arad, Ronen @ 2014-12-06 8:05 UTC (permalink / raw)
To: Scott Feldman, Netdev
Cc: Roopa Prabhu, Jirí Pírko, Jamal Hadi Salim,
Benjamin LaHaise, Thomas Graf, john fastabend,
stephen@networkplumber.org, John Linville, nhorman@tuxdriver.com,
Nicolas Dichtel, vyasevic@redhat.com, Florian Fainelli,
buytenh@wantstofly.org, Aviad Raveh, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <CAE4R7bChFLfCX5z4FTWHfnpNuYKnkTtD64xg5BE0yAwA381w3g@mail.gmail.com>
> -----Original Message-----
> From: Scott Feldman [mailto:sfeldma@gmail.com]
> Sent: Friday, December 05, 2014 10:29 PM
> To: Arad, Ronen
> Cc: Roopa Prabhu; Netdev; Jirí Pírko; Jamal Hadi Salim; Benjamin LaHaise;
> Thomas Graf; john fastabend; stephen@networkplumber.org; John Linville;
> nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
> Fainelli; buytenh@wantstofly.org; Aviad Raveh; David S. Miller;
> shm@cumulusnetworks.com; Andy Gospodarek
> Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic
> if feature flag set
>
> On Fri, Dec 5, 2014 at 5:04 PM, Arad, Ronen <ronen.arad@intel.com> wrote:
> > I have another case of propagation which is not covered by the proposed
> patch.
> > A recent patch introduced default_pvid attribute for a bridge (so far
> supported only via sysfs and not via netlink).
> > When a port joins a bridge, it inherits a PVID from the default_pvid of the
> bridge.
> > The bridge driver propagates that to the newly created net_bridge_port.
> This is done in br_vlan.c:
> >
> > int nbp_vlan_init(struct net_bridge_port *p) {
> > int rc = 0;
> >
> > if (p->br->default_pvid) {
> > rc = nbp_vlan_add(p, p->br->default_pvid,
> > BRIDGE_VLAN_INFO_PVID |
> > BRIDGE_VLAN_INFO_UNTAGGED);
> > }
> >
> > return rc;
> > }
> >
> > When L2 switching is offloaded to the HW, this PVID setting need to be
> propagated.
>
> Agreed, it would be nice to have it propagated down, but there is a non-ideal
> work-around. If you set default_pvid=0 to turn off PVID, then the switch port
> driver can pick some internal VLAN ID just for HW purposes in matching
> untagged pkts. It's non-ideal because the switch port driver needs to reserve
> a block of VLAN IDs for internal usage or use some other matching
> mechanism to keep untagged pkts within this bridge.
This work-around let the administrator avoid using VID=1 as the default VLAN for untagged frames. However, it does not let the administrator pick a VID of her choice.
>
> Better to have default_pvid value propagated down. But, default_pvid is a
> per-bridge property, not a per-bridge-port property.
> RTM_SETLINK/RTM_GETLINK for PF_BRIDGE does have AFSPEC for per-bridge
> and PROTINFO for per-bridge-port, so it seems PVID needs to be part of
> AFSPEC.
I believe AFSPEC is not limited to per-bridge properties. It is per-bridge when the netlink msg's ifindex is that of a bridge and SELF flag is set.
AFSPEC is for a port when the netlink msg's ifindex is that of an enslaved port device and MASTER flag is set (or neither MASTER nor SELF flag is set)
PVID is one of the flags associated with a VID in bridge_vlan_info.
default_pvid is not currently supported by netlink. A new IFLA_BRIDGE_DEFAULT_PVID could be introduced to carry this property when a nlmsg is directed at a bridge.
>
> >However, it does not come via ndo_bridge_setlink. The proposed
> propagation at br_setlink or an up level one at rtnetlink are not capable of
> handling this case.
> > One possible way for handling that is to replace the call to
> >nbp_vlan_add with a call to a new function let's say int
> >br_propagate_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags)
> This function will compose a netlink message with VLAN filtering information
> (i.e. AF_SPEC with VLAN_INFO) and call br_setlink - leveraging the offload
> support proposed by Roopa.
> >
> > If this is an acceptable course of action, I could work on such patch.
> >
> >
> >> -----Original Message-----
> >> From: netdev-owner@vger.kernel.org [mailto:netdev-
> >> owner@vger.kernel.org] On Behalf Of Arad, Ronen
> >> Sent: Friday, December 05, 2014 3:21 PM
> >> To: Roopa Prabhu; Scott Feldman; Netdev
> >> Cc: Jirí Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
> >> fastabend; stephen@networkplumber.org; John Linville;
> >> nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
> >> Fainelli; buytenh@wantstofly.org; Aviad Raveh; David S. Miller;
> >> shm@cumulusnetworks.com; Andy Gospodarek
> >> Subject: RE: [PATCH 2/3] bridge: offload bridge port attributes to
> >> switch asic if feature flag set
> >>
> >>
> >>
<snip>
^ permalink raw reply
* [PATCH v3 iproute2] bridge link: add option 'self'
From: roopa @ 2014-12-06 8:21 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
linville, vyasevic
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Currently self is set internally only if hwmode is set.
This makes it necessary for the hw to have a mode.
There is no hwmode really required to go to hardware. So, introduce
self for anybody who wants to target hardware.
v1 -> v2
- fix a few bugs. Initialize flags to zero: this was required to
keep the current behaviour unchanged.
v2 -> v3
- fix comment
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
bridge/link.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/bridge/link.c b/bridge/link.c
index 90d9e7f..3f77aab 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -261,7 +261,7 @@ static int brlink_modify(int argc, char **argv)
__s16 priority = -1;
__s8 state = -1;
__s16 mode = -1;
- __u16 flags = BRIDGE_FLAGS_MASTER;
+ __u16 flags = 0;
struct rtattr *nest;
memset(&req, 0, sizeof(req));
@@ -321,6 +321,8 @@ static int brlink_modify(int argc, char **argv)
"\"veb\".\n");
exit(-1);
}
+ } else if (strcmp(*argv, "self") == 0) {
+ flags = BRIDGE_FLAGS_SELF;
} else {
usage();
}
@@ -369,16 +371,16 @@ static int brlink_modify(int argc, char **argv)
addattr_nest_end(&req.n, nest);
- /* IFLA_AF_SPEC nested attribute. Contains IFLA_BRIDGE_FLAGS that
- * designates master or self operation as well as 'vepa' or 'veb'
- * operation modes. These are only valid in 'self' mode on some
- * devices so far. Thus we only need to include the flags attribute
- * if we are setting the hw mode.
+ /* IFLA_AF_SPEC nested attribute. Contains IFLA_BRIDGE_FLAGS that
+ * designates master or self operation and IFLA_BRIDGE_MODE
+ * for hw 'vepa' or 'veb' operation modes. The hwmodes are
+ * only valid in 'self' mode on some devices so far.
*/
- if (mode >= 0) {
+ if (mode >= 0 || flags > 0) {
nest = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
- addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
+ if (flags > 0)
+ addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
if (mode >= 0)
addattr16(&req.n, sizeof(req), IFLA_BRIDGE_MODE, mode);
--
1.7.10.4
^ permalink raw reply related
* [PATCH] netfilter: Fix build for NETFILTER_XT_TARGET_REDIRECT
From: Guenter Roeck @ 2014-12-06 9:41 UTC (permalink / raw)
To: netfilter-devel
Cc: coreteam, netdev, Guenter Roeck, Pablo Neira Ayuso,
Arturo Borrero Gonzalez
Fix:
ERROR: "nf_nat_redirect_ipv6" [net/netfilter/xt_REDIRECT.ko] undefined!
Seen if NETFILTER_XT_TARGET_REDIRECT is configured but NF_NAT_IPV6
is not, since code compiled with NF_NAT_REDIRECT_IPV6 is used
unconditionally by code enabled with NETFILTER_XT_TARGET_REDIRECT.
This means that NETFILTER_XT_TARGET_REDIRECT depends on NF_NAT_IPV6
and must always select NF_NAT_REDIRECT_IPV6.
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
Seen in and applies to -next. See various qemu test failures
reported at http://server.roeck-us.net:8010/builders,
net/netfilter/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 57f15a9..2134ef0 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -843,9 +843,9 @@ config NETFILTER_XT_TARGET_RATEEST
config NETFILTER_XT_TARGET_REDIRECT
tristate "REDIRECT target support"
- depends on NF_NAT
+ depends on NF_NAT && NF_NAT_IPV6
select NF_NAT_REDIRECT_IPV4 if NF_NAT_IPV4
- select NF_NAT_REDIRECT_IPV6 if NF_NAT_IPV6
+ select NF_NAT_REDIRECT_IPV6
---help---
REDIRECT is a special case of NAT: all incoming connections are
mapped onto the incoming interface's address, causing the packets to
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/3] netdev: introduce new NETIF_F_HW_SWITCH_OFFLOAD feature flag for switch device offloads
From: Thomas Graf @ 2014-12-06 10:14 UTC (permalink / raw)
To: Roopa Prabhu
Cc: jiri, sfeldma, jhs, bcrl, john.fastabend, stephen, linville,
nhorman, nicolas.dichtel, vyasevic, f.fainelli, buytenh, aviadr,
netdev, davem, shm, gospo
In-Reply-To: <5482B44F.2050509@cumulusnetworks.com>
On 12/05/14 at 11:46pm, Roopa Prabhu wrote:
> On 12/5/14, 2:43 PM, Thomas Graf wrote:
> >On 12/04/14 at 06:26pm, roopa@cumulusnetworks.com wrote:
> >>From: Roopa Prabhu <roopa@cumulusnetworks.com>
> >>
> >>This is a generic high level feature flag for all switch asic features today.
> >>
> >>switch drivers set this flag on switch ports. Logical devices like
> >>bridge, bonds, vxlans can inherit this flag from their slaves/ports.
> >>
> >>I had to use SWITCH in the name to avoid ambiguity with other feature
> >>flags. But, since i have been harping about not calling it 'switch',
> >>I am welcome to any suggestions :)
> >>
> >>An alternative to using a feature flag is to use a IFF_HW_OFFLOAD
> >>in net_device_flags.
> >What does this flag indicate specifically? What driver would
> >implement ndo_bridge_setlink() but not set this flag?
> >
> >I think it should be clearly documented when this flag is to bet set.
> I mentioned it as an alternative because it was there in my RFC patch. There
> is no code for it yet.
> And I will get rid of the comment in v2.
Sorry, I was referring to NETIF_F_HW_SWITCH_OFFLOAD. I do not
understand the scope of this bit/flag yet. Can you give examples
when to set this bit? At what point would the existing ixgbe FDB
offload set this bit? Is there a case when ndo_bridge_setlink()
is implemented but this bit is not set?
^ permalink raw reply
* Re: [PATCH] iproute2: Add support for CAN presume-ack feature
From: Oliver Hartkopp @ 2014-12-06 10:33 UTC (permalink / raw)
To: Nikita Edward Baruzdin, linux-can, netdev
In-Reply-To: <1417768902-5404-2-git-send-email-nebaruzdin@gmail.com>
On 05.12.2014 09:41, Nikita Edward Baruzdin wrote:
> This patch makes CAN_CTRLMODE_PRESUME_ACK netlink feature configurable.
> When enabled, the feature sets CAN controller in mode in which
> acknowledgement absence is ignored.
>
> Signed-off-by: Nikita Edward Baruzdin <nebaruzdin@gmail.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Hi Nikita,
I just noticed that you only posted to linux-can ML last time - so it didn't
reach the iproute and netdev guys like Stephen Hemminger ...
Thanks for posting it again to the appropriate MLs.
Best regards,
Oliver
> ---
> ip/iplink_can.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/ip/iplink_can.c b/ip/iplink_can.c
> index 5b92426..fb50332 100644
> --- a/ip/iplink_can.c
> +++ b/ip/iplink_can.c
> @@ -37,6 +37,7 @@ static void print_usage(FILE *f)
> "\t[ one-shot { on | off } ]\n"
> "\t[ berr-reporting { on | off } ]\n"
> "\t[ fd { on | off } ]\n"
> + "\t[ presume-ack { on | off } ]\n"
> "\n"
> "\t[ restart-ms TIME-MS ]\n"
> "\t[ restart ]\n"
> @@ -99,6 +100,7 @@ static void print_ctrlmode(FILE *f, __u32 cm)
> _PF(CAN_CTRLMODE_ONE_SHOT, "ONE-SHOT");
> _PF(CAN_CTRLMODE_BERR_REPORTING, "BERR-REPORTING");
> _PF(CAN_CTRLMODE_FD, "FD");
> + _PF(CAN_CTRLMODE_PRESUME_ACK, "PRESUME-ACK");
> #undef _PF
> if (cm)
> fprintf(f, "%x", cm);
> @@ -201,6 +203,10 @@ static int can_parse_opt(struct link_util *lu, int argc, char **argv,
> NEXT_ARG();
> set_ctrlmode("fd", *argv, &cm,
> CAN_CTRLMODE_FD);
> + } else if (matches(*argv, "presume-ack") == 0) {
> + NEXT_ARG();
> + set_ctrlmode("presume-ack", *argv, &cm,
> + CAN_CTRLMODE_PRESUME_ACK);
> } else if (matches(*argv, "restart") == 0) {
> __u32 val = 1;
>
>
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pavel Machek @ 2014-12-06 12:49 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Pali Rohár, Ming Lei, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Ivaylo Dimitrov, Aaro Koskinen,
Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <20141127155840.GC24149@kroah.com>
On Thu 2014-11-27 07:58:40, Greg Kroah-Hartman wrote:
> On Thu, Nov 27, 2014 at 04:22:58PM +0100, Pali Rohár wrote:
> > On Thursday 27 November 2014 16:16:55 Greg Kroah-Hartman wrote:
> > > On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
> > > > On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
> > > > > On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
> > > >
> > > > <pali.rohar@gmail.com> wrote:
> > > > > > Hello,
> > > > > >
> > > > > > wifi driver wl1251 needs NVS calibration data for
> > > > > > working. These data are loaded by driver via
> > > > > > request_firmware from userspace file:
> > > > > > ti-connectivity/wl1251-nvs.bin. In linux-fimrware git
> > > > > > tree there is generic wl1251-nvs.bin file which is used
> > > > > > by default.
> > > > > >
> > > > > > Driver wl1251 is used on Nokia N900 cellphone for its
> > > > > > wifi chip. This cellphone has one special MTD partition
> > > > > > (called CAL) where are stored some configuration data
> > > > > > in special binary (key-value) format. And there is also
> > > > > > stored correct calibration data for specific device
> > > > > > (each device has different data). It is preferred to
> > > > > > use those data instead generic one (provided by
> > > > > > linux-firmware git tree).
> > > > > >
> > > > > > Now my question is: How to correctly load calibration
> > > > > > data from special Nokia N900 CAL partition into wl1251
> > > > > > kernel driver?
> > > > >
> > > > > It is better to let user space script handle the request.
> > > >
> > > > Yes, this makes sense. Implementing CAL parser in kernel
> > > > wl1251 driver would be hard...
> > > >
> > > > > > By default kernel reads ti-connectivity/wl1251-nvs.bin
> > > > > > file from VFS if exists without any userspace support.
> > > > > > If it fails then it fallback to loading via udev.
> > > > >
> > > > > You can remove or rename this file so that loading from
> > > > > user space can be triggered.
> > > >
> > > > It is no so easy... In case when CAL does not contains NVS
> > > > data then we want to use this generic NVS file. And telling
> > > > everybody to rename this is file is not good solution...
> > >
> > > But that's up to your system configuration, not the kernel.
> > > Make a userspace package for the firmware that creates it in
> > > the format you need it to be in, for the hardware you have,
> > > and then there would not be any need for a kernel change,
> > > right?
> > >
> > > greg k-h
> >
> > Not so simple as you think. Some parts of NVS data are configured
> > based on location and cellular station. Data are not static.
>
> Then you need a dynamic program that you control, in userspace, to dump
> the needed data into the kernel. Don't try to do it with "static"
> firmware files. Use the binary sysfs file interface for this if you
> want.
Actually, this seems to be similar situation to fpga programming.
There, it is static firmware for 90% users, but some special use cases
want it more dynamic.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-06 13:00 UTC (permalink / raw)
To: Ming Lei
Cc: John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Greg Kroah-Hartman, Pavel Machek,
Ivaylo Dimitrov, Aaro Koskinen, Kalle Valo, Sebastian Reichel,
David Gnedt
In-Reply-To: <CACVXFVMCJxQRUo94C8peT7G-VFkVeNYCWGKPYE5jq=twCULrpA@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 1089 bytes --]
On Thursday 27 November 2014 16:13:51 Ming Lei wrote:
> > Which userspace helper programs for (automatic) firmware
> > loading are used? Can be udev configured to use own program
> > for loading
>
> At default, udev had its builtin firmware helper, but some new
> udev stops to handle firmware request.
>
> If the udev you are using still supports to handle firmware
> request, you can write your load helper and add your rule for
> handling the special case. Otherwise, you need to write code
> to monitor the netlink uevents from the kernel and handle
> your firmware loading request.
>
> Thanks,
> Ming Lei
For Nokia N900 (and Maemo system) we are using older udev version
(0.125), so here should be support for firmware helper.
And if some new udev version will not work, we can just revert
back to older working... No need to use super-uber-fantastic
systemd-udevd software which removing old useful code.
So looks like adding new rule file to udev for handling firmware
requests from kernel could work...
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
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