* [net-next,iproute2] netconf: add support for ignore route attribute
From: Zhang Shengju @ 2016-03-14 4:55 UTC (permalink / raw)
To: stephen; +Cc: netdev
Add support for ignore_routes_with_linkdown attribute.
Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
---
ip/ipnetconf.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/ip/ipnetconf.c b/ip/ipnetconf.c
index eca6eee..6fec818 100644
--- a/ip/ipnetconf.c
+++ b/ip/ipnetconf.c
@@ -119,6 +119,10 @@ int print_netconf(const struct sockaddr_nl *who, struct rtnl_ctrl_data *ctrl,
fprintf(fp, "proxy_neigh %s ",
*(int *)RTA_DATA(tb[NETCONFA_PROXY_NEIGH])?"on":"off");
+ if (tb[NETCONFA_IGNORE_ROUTES_WITH_LINKDOWN])
+ fprintf(fp, "ignore_routes_with_linkdown %s ",
+ *(int *)RTA_DATA(tb[NETCONFA_IGNORE_ROUTES_WITH_LINKDOWN])?"on":"off");
+
fprintf(fp, "\n");
fflush(fp);
return 0;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3 net-next 0/2] net: hns: get and set RSS indirection table by using ethtool
From: Yankejian (Hackim Yim) @ 2016-03-14 4:27 UTC (permalink / raw)
To: Andy Shevchenko, davem
Cc: yisen.zhuang, salil.mehta, liguozhu, huangdaode, arnd, andrew,
chenny.xu, ivecera, lisheng011, fengguang.wu, haifeng.wei, netdev,
linux-kernel, linux-arm-kernel, linuxarm
In-Reply-To: <1457686918.1347.56.camel@linux.intel.com>
On 2016/3/11 17:01, Andy Shevchenko wrote:
> On Fri, 2016-03-11 at 11:25 +0800, Kejian Yan wrote:
>> When we use ethtool to retrieves or configure the receive flow hash
>> indirection table, ethtool needs to call .get_rxnfc to get the ring
>> number
>> so this patchset implements the .get_rxnfc and fixes the bug that we
>> can
>> not get the tatal table each time.
>>
> FWIW:
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Hi Andy,
I'm sorry for missing it.i will fix it in next submit.
MBR, Kejian
>> ---
>> change log:
>> PATCH v3:
>> - This patchset fixes the building warning and error
>>
>> PATCH v2:
>> - This patchset fixes the comments provided by Andy Shevchenko <Andy
>> Shevchenko>
>>
>> PATCH v1:
>> - first submit
>>
>> Kejian Yan (2):
>> net: hns: fix return value of the function about rss
>> net: hns: fixes a bug of RSS
>>
>> drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 8 ++++---
>> drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 2 +-
>> drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 28
>> ++++++++++++++++-------
>> 3 files changed, 26 insertions(+), 12 deletions(-)
>>
^ permalink raw reply
* Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing
From: David Miller @ 2016-03-14 3:53 UTC (permalink / raw)
To: maheshb; +Cc: mahesh, edumazet, netdev
In-Reply-To: <CAF2d9jhtvvEdmwP8OrOcUEn+P-Di0TRnjR7-RpcJrKJ3+HAN-Q@mail.gmail.com>
From: Mahesh Bandewar <maheshb@google.com>
Date: Sun, 13 Mar 2016 19:29:58 -0700
> On Sun, Mar 13, 2016 at 6:50 PM, David Miller <davem@davemloft.net> wrote:
>> It doesn't matter whether doing so or not makes sense.
>>
>> You're going to have to find a way to do both, and also I'm concerned
>> about how you're leaking the source namespace's "stuff" into the
>> destination's. That's very worrisome to me.
>
> If we add a new mode (e.g. L3s) and preserve current mode as is it,
> then that should address your first concern.
Also, I don't want all of this device translation stuff all over the
place.
Furthermore, when you walk across the ns boundary, that old device has
to disappear. That's why that is the device assigned to skb->dev.
Please stop pretending that this device switching is ok, it's not.
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: David Miller @ 2016-03-14 3:29 UTC (permalink / raw)
To: gorcunov
Cc: xiyou.wangcong, alexei.starovoitov, eric.dumazet, netdev, solar,
vvs, avagin, xemul, vdavydov, khorenko, pablo, netfilter-devel
In-Reply-To: <20160311215912.GI1989@uranus.lan>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Sat, 12 Mar 2016 00:59:12 +0300
> Here is a cumulative one, which works just brilliant! Thanks a lot, David!
> (I cahcnged reported-by tag, since it's Solar Designer who tell us
> about the issue, I forgot to mentioned it in first report, very
> sorry).
Thanks for fixing this up and retesting, applied and queued up for -stable.
^ permalink raw reply
* Re: [GIT] [4.6] NFC update
From: David Miller @ 2016-03-14 2:43 UTC (permalink / raw)
To: sameo; +Cc: linux-nfc, netdev
In-Reply-To: <20160311204857.GB29902@zurbaran.home>
From: Samuel Ortiz <sameo@linux.intel.com>
Date: Fri, 11 Mar 2016 21:48:57 +0100
> This is a very small one this time, with only 5 patches.
> There are a couple of big items that could not be merged/finished
> on time.
>
> We have:
>
> - 2 LLCP fixes for a race and a potential OOM.
> - 2 cleanups for the pn544 and microread drivers.
> - 1 Maintainer addition for the s3fwrn5 driver.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] MACsec IEEE 802.1AE implementation
From: David Miller @ 2016-03-14 2:41 UTC (permalink / raw)
To: sd; +Cc: netdev, johannes, hannes, fw, pabeni, stephen
In-Reply-To: <cover.1457714618.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Fri, 11 Mar 2016 18:07:30 +0100
> MACsec (IEEE 802.1AE [0]) is a protocol that provides security for
> wired ethernet LANs. MACsec offers two protection modes:
> authentication only, or authenticated encryption.
...
> Implementation
...
> Netlink API
...
> Use cases
...
Probably one of the best cover letters for a new feature written in
quite a while, nice work.
Series applied, thanks!
^ permalink raw reply
* Re: [PATCH] at803x: fix suspend/resume for SGMII link
From: David Miller @ 2016-03-14 2:37 UTC (permalink / raw)
To: zefir.kurtisi; +Cc: netdev, f.fainelli, chunkeey
In-Reply-To: <1457706713-13779-1-git-send-email-zefir.kurtisi@neratec.com>
From: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Date: Fri, 11 Mar 2016 15:31:53 +0100
> When operating the at803x in SGMII mode, resuming the chip
> from power down brings up the copper-side link but leaves
> the SGMII link in unconnected state (tested with at8031
> attached to gianfar). In effect, this caused a permanent
> link loss once the related interface was put down.
>
> This patch ensures that power down handling in supspend()
> and resume() is also applied to the SGMII link.
>
> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next PATCH V4 0/3] net: bulk free adjustment and two driver use-cases
From: David Miller @ 2016-03-14 2:35 UTC (permalink / raw)
To: brouer
Cc: netdev, sergei.shtylyov, eugenia, alexander.duyck,
alexei.starovoitov, saeedm, gerlitz.or
In-Reply-To: <20160311084245.5207.70640.stgit@firesoul>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Fri, 11 Mar 2016 09:43:48 +0100
> I've split out the bulk free adjustments, from the bulk alloc patches,
> as I want the adjustment to napi_consume_skb be in same kernel cycle
> the API was introduced.
>
> Adjustments based on discussion:
> Subj: "mlx4: use napi_consume_skb API to get bulk free operations"
> http://thread.gmane.org/gmane.linux.network/402503/focus=403386
>
> Patchset based on net-next at commit 3ebeac1d0295
>
> V4: more nitpicks from Sergei
> V3: spelling fixes from Sergei
Series applied, thanks Jesper.
^ permalink raw reply
* Re: [PATCH net v2] r8169:Remove unnecessary phy reset for pcie nic when setting link spped.
From: David Miller @ 2016-03-14 2:33 UTC (permalink / raw)
To: hau; +Cc: netdev, nic_swsd, linux-kernel
In-Reply-To: <1457677274-2248-1-git-send-email-hau@realtek.com>
From: Chunhao Lin <hau@realtek.com>
Date: Fri, 11 Mar 2016 14:21:14 +0800
> For pcie nic, after setting link speed and there is no link driver does not need
> to do phy reset until link up.
>
> For some pcie nics, to do this will also reset phy speed down counter and prevent
> phy from auto speed down.
>
> This patch fix the issue reported in following link.
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1547151
>
> Signed-off-by: Chunhao Lin <hau@realtek.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next] mlxsw: pci: Implement reset done check
From: David Miller @ 2016-03-14 2:30 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, eladr, yotamg, ogerlitz
In-Reply-To: <1457647821-2839-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 10 Mar 2016 23:10:21 +0100
> From: Jiri Pirko <jiri@mellanox.com>
>
> Firmware now tells us that the reset is done by passing a magic value
> via register. Use it to shorten the wait in case this is supported.
> With old firmware, we still wait until the timeout is reached.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing
From: Mahesh Bandewar @ 2016-03-14 2:29 UTC (permalink / raw)
To: David Miller; +Cc: mahesh, Eric Dumazet, linux-netdev
In-Reply-To: <20160313.215033.17951850162749485.davem@davemloft.net>
On Sun, Mar 13, 2016 at 6:50 PM, David Miller <davem@davemloft.net> wrote:
> From: Mahesh Bandewar <mahesh@bandewar.net>
> Date: Wed, 9 Mar 2016 13:49:49 -0800
>
>> This does happen as expected for egress traffic however on ingress
>> traffic, the IPvlan packet-handler changes the skb->dev and this
>> forces packet to be processed with the IPvlan slave and it's
>> associated ns. This causes above mentioned problem and few other
>> which are not yet reported / attempted. e.g. IPsec with L3 mode or
>> even ingress routing.
>
> And now your changes make it so that we can't run netfilter rules on
> the slave's device within the slave's ns.
>
> If someone is doing that now you're breaking things for them.
>
Yes, I agree. If someone is using netfilter hooks in slave-ns, then this would
break for them. If we do this as a separate mode (e.g. L3s) keeping the
current mode as it is. Would that be an acceptable solution?
> It doesn't matter whether doing so or not makes sense.
>
> You're going to have to find a way to do both, and also I'm concerned
> about how you're leaking the source namespace's "stuff" into the
> destination's. That's very worrisome to me.
>
If we add a new mode (e.g. L3s) and preserve current mode as is it, then
that should address your first concern.
Now about leaking ns "stuff". I do not want to leak stuff across ns. In the
current L3 mode there is an issue that Nicolas has pointed out and I'll fix
that soon. In the new mode (L3s); right from the beginning the L2 and L3
processing always (and consistently) will happen with master device
(proposed skb->dev->l3_dev).
> There is no way I'm applying this as-is, sorry.
^ permalink raw reply
* Re: [PATCH] sctp: allow sctp_transmit_packet and others to use gfp
From: David Miller @ 2016-03-14 2:29 UTC (permalink / raw)
To: marcelo.leitner; +Cc: netdev, vyasevich, nhorman, linux-sctp
In-Reply-To: <90a118e4ca996adb067290a6c45fca6564a77423.1457644344.git.marcelo.leitner@gmail.com>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Thu, 10 Mar 2016 18:33:07 -0300
> Currently sctp_sendmsg() triggers some calls that will allocate memory
> with GFP_ATOMIC even when not necessary. In the case of
> sctp_packet_transmit it will allocate a linear skb that will be used to
> construct the packet and this may cause sends to fail due to ENOMEM more
> often than anticipated specially with big MTUs.
>
> This patch thus allows it to inherit gfp flags from upper calls so that
> it can use GFP_KERNEL if it was triggered by a sctp_sendmsg call or
> similar. All others, like retransmits or flushes started from BH, are
> still allocated using GFP_ATOMIC.
>
> In netperf tests this didn't result in any performance drawbacks when
> memory is not too fragmented and made it trigger ENOMEM way less often.
>
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v5] tcp: Add RFC4898 tcpEStatsPerfDataSegsOut/In
From: David Miller @ 2016-03-14 2:21 UTC (permalink / raw)
To: kafai; +Cc: netdev, kernel-team, rapier, edumazet, mleitner, ncardwell,
ycheng
In-Reply-To: <1457635582-2979568-1-git-send-email-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Thu, 10 Mar 2016 10:46:22 -0800
> Per RFC4898, they count segments sent/received
> containing a positive length data segment (that includes
> retransmission segments carrying data). Unlike
> tcpi_segs_out/in, tcpi_data_segs_out/in excludes segments
> carrying no data (e.g. pure ack).
>
> The patch also updates the segs_in in tcp_fastopen_add_skb()
> so that segs_in >= data_segs_in property is kept.
>
> Together with retransmission data, tcpi_data_segs_out
> gives a better signal on the rxmit rate.
>
> v5: Eric pointed out that checking skb->len is still needed in
> tcp_fastopen_add_skb() because skb can carry a FIN without data.
> Hence, instead of open coding segs_in and data_segs_in, tcp_segs_in()
> helper is used. Comment is added to the fastopen case to explain why
> segs_in has to be reset and tcp_segs_in() has to be called before
> __skb_pull().
>
> v4: Add comment to the changes in tcp_fastopen_add_skb()
> and also add remark on this case in the commit message.
>
> v3: Add const modifier to the skb parameter in tcp_segs_in()
>
> v2: Rework based on recent fix by Eric:
> commit a9d99ce28ed3 ("tcp: fix tcpi_segs_in after connection establishment")
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
This doesn't apply cleanly to net-next, please respin.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next] ovs: allow nl 'flow set' to use ufid without flow key
From: David Miller @ 2016-03-14 2:20 UTC (permalink / raw)
To: samuel.gauthier-pdR9zngts4EAvxtiuMwx3w
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1457626499-26585-1-git-send-email-samuel.gauthier-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
From: Samuel Gauthier <samuel.gauthier@6wind.com>
Date: Thu, 10 Mar 2016 17:14:59 +0100
> When we want to change a flow using netlink, we have to identify it to
> be able to perform a lookup. Both the flow key and unique flow ID
> (ufid) are valid identifiers, but we always have to specify the flow
> key in the netlink message. When both attributes are there, the ufid
> is used. The flow key is used to validate the actions provided by
> the userland.
>
> This commit allows to use the ufid without having to provide the flow
> key, as it is already done in the netlink 'flow get' and 'flow del'
> path. The flow key remains mandatory when an action is provided.
>
> Signed-off-by: Samuel Gauthier <samuel.gauthier@6wind.com>
Applied.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH] net: macb: fix default configuration for GMAC on AT91
From: David Miller @ 2016-03-14 2:20 UTC (permalink / raw)
To: nicolas.ferre
Cc: linux-arm-kernel, netdev, cyrille.pitchen, linux-kernel,
alexandre.belloni, boris.brezillon, romain.henriet, michal.simek,
punnaia
In-Reply-To: <1457624672-30666-1-git-send-email-nicolas.ferre@atmel.com>
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Thu, 10 Mar 2016 16:44:32 +0100
> On AT91 SoCs, the User Register (USRIO) exposes a switch to configure the
> "Reduced" or "Traditional" version of the Media Independent Interface
> (RMII vs. MII or RGMII vs. GMII).
> As on the older EMAC version, on GMAC, this switch is set by default to the
> non-reduced type of interface, so use the existing capability and extend it to
> GMII as well. We then keep the current logic in the macb_init() function.
>
> The capabilities of sama5d2, sama5d4 and sama5d3 GEM interface are updated in
> the macb_config structure to be able to properly enable them with a traditional
> interface (GMII or MII).
>
> Reported-by: Romain HENRIET <romain.henriet@l-acoustics.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] net/forcedeth: refactor wol support to make it easier to add more wol modes
From: David Miller @ 2016-03-14 2:14 UTC (permalink / raw)
To: git; +Cc: linux-kernel, netdev
In-Reply-To: <1457621884-2479-2-git-send-email-git@karolherbst.de>
From: Karol Herbst <git@karolherbst.de>
Date: Thu, 10 Mar 2016 15:58:03 +0100
> @@ -4218,8 +4219,9 @@ static void nv_get_wol(struct net_device *dev, struct ethtool_wolinfo *wolinfo)
> wolinfo->supported = WAKE_MAGIC;
>
> spin_lock_irq(&np->lock);
> - if (np->wolenabled)
> - wolinfo->wolopts = WAKE_MAGIC;
> + wolinfo->wolopts = 0;
> + if (np->wolenabled & WAKE_MAGIC)
> + wolinfo->wolopts |= WAKE_MAGIC;
> spin_unlock_irq(&np->lock);
> }
>
When I see a change like this I can see you don't understand the
contract that exists between the ethtool core layer and your
driver.
The command info struct, in this case 'wolinfo' passed to you is
zero'd out, always.
Therefore the part of the change explicitly clearing out
wolinfo->wolopts is completely unnecessary and needs to be removed.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] phy: remove documentation of removed members of phy_device structure
From: David Miller @ 2016-03-14 2:11 UTC (permalink / raw)
To: clabbe.montjoie; +Cc: f.fainelli, netdev, linux-kernel
In-Reply-To: <1457614738-17337-1-git-send-email-clabbe.montjoie@gmail.com>
From: LABBE Corentin <clabbe.montjoie@gmail.com>
Date: Thu, 10 Mar 2016 13:58:58 +0100
> Commit e5a03bfd873c ("phy: Add an mdio_device structure") removed addr,
> bus and dev member of the phy_device structure.
> This patch remove the documentation about those members.
>
> Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/3] xen-netback: fix multiple extra info handling
From: David Miller @ 2016-03-14 2:08 UTC (permalink / raw)
To: paul.durrant; +Cc: netdev, xen-devel
In-Reply-To: <1457613028-10381-1-git-send-email-paul.durrant@citrix.com>
From: Paul Durrant <paul.durrant@citrix.com>
Date: Thu, 10 Mar 2016 12:30:25 +0000
> If a frontend passes multiple extra info fragments to netback on the guest
> transmit side, because xen-netback does not account for this properly, only
> a single ack response will be sent. This will eventually cause processing
> of the shared ring to wedge.
>
> This series re-imports the canonical netif.h from Xen, where the ring
> protocol documentation has been updated, fixes this issue in xen-netback
> and also adds a patch to reduce log spam.
Series applied, thanks Paul.
^ permalink raw reply
* Re: [PATCH v5 net-next 00/10] API set for HW Buffer management
From: David Miller @ 2016-03-14 2:02 UTC (permalink / raw)
To: gregory.clement
Cc: linux-kernel, netdev, thomas.petazzoni, f.fainelli, jason, andrew,
sebastian.hesselbarth, linux-arm-kernel, alior, nadavh, mw,
simon.guinot, linux, w, timork, dima, nitroshift
In-Reply-To: <1457604558-1121-1-git-send-email-gregory.clement@free-electrons.com>
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date: Thu, 10 Mar 2016 11:09:08 +0100
> This is the fifth version of the API set for HW Buffer management (that was
> initially submitted here:
> http://thread.gmane.org/gmane.linux.kernel/2125152).
This doesn't apply cleanly to net-next, please respin.
^ permalink raw reply
* ethtool 4.5 released
From: Ben Hutchings @ 2016-03-14 1:58 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]
ethtool version 4.5 has been released.
Home page: https://www.kernel.org/pub/software/network/ethtool/
Download link:
https://www.kernel.org/pub/software/network/ethtool/ethtool-4.5.tar.xz
Release notes:
* Tests: Fix missing function declarations when building tests
* Tests: Fix return type of test_free() prorotype
* Feature: Add PHY statistics support (--phy-statistics option)
* Doc: Properly indent sub-options in man page
* Feature: Support setting default Rx flow indirection table
(-X option)
* Fix: Use 'sane' kernel type definitions on 64-bit architectures
* Fix: Don't ignore fread() return value (-d option)
* Fix: Heap corruption when dumping registers from a file (-d option)
* Fix: Stricter input validation for EEPROM setting (-E option)
* Fix: Fix strict-aliasing compiler warnings in marvell.c
* Tests: Fix use of uninitialised variable in test_realloc()
* Tests: Fix compiler warning in test-features.c
Ben.
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [net-next] netconf: add macro to represent all attributes
From: David Miller @ 2016-03-14 1:54 UTC (permalink / raw)
To: zhangshengju; +Cc: netdev
In-Reply-To: <1457600150-2903-1-git-send-email-zhangshengju@cmss.chinamobile.com>
From: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
Date: Thu, 10 Mar 2016 08:55:50 +0000
> This patch adds macro NETCONFA_ALL to represent all type of netconf
> attributes for IPv4 and IPv6.
>
> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] sctp: fix the transports round robin issue when init is retransmitted
From: David Miller @ 2016-03-14 1:53 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, vyasevich, daniel
In-Reply-To: <8d3cd163c84b30797f1123a7fc8a56f768801a87.1457595117.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Thu, 10 Mar 2016 15:31:57 +0800
> prior to this patch, at the beginning if we have two paths in one assoc,
> they may have the same params other than the last_time_heard, it will try
> the paths like this:
>
> 1st cycle
> try trans1 fail.
> then trans2 is selected.(cause it's last_time_heard is after trans1).
>
> 2nd cycle:
> try trans2 fail
> then trans2 is selected.(cause it's last_time_heard is after trans1).
>
> 3rd cycle:
> try trans2 fail
> then trans2 is selected.(cause it's last_time_heard is after trans1).
>
> ....
>
> trans1 will never have change to be selected, which is not what we expect.
> we should keeping round robin all the paths if they are just added at the
> beginning.
>
> So at first every tranport's last_time_heard should be initialized 0, so
> that we ensure they have the same value at the beginning, only by this,
> all the transports could get equal chance to be selected.
>
> Then for sctp_trans_elect_best, it should return the trans_next one when
> *trans == *trans_next, so that we can try next if it fails, but now it
> always return trans. so we can fix it by exchanging these two params when
> we calls sctp_trans_elect_tie().
>
> Fixes: 4c47af4d5eb2 ('net: sctp: rework multihoming retransmission path selection to rfc4960')
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing
From: David Miller @ 2016-03-14 1:50 UTC (permalink / raw)
To: mahesh; +Cc: maheshb, edumazet, netdev
In-Reply-To: <1457560189-12870-1-git-send-email-mahesh@bandewar.net>
From: Mahesh Bandewar <mahesh@bandewar.net>
Date: Wed, 9 Mar 2016 13:49:49 -0800
> This does happen as expected for egress traffic however on ingress
> traffic, the IPvlan packet-handler changes the skb->dev and this
> forces packet to be processed with the IPvlan slave and it's
> associated ns. This causes above mentioned problem and few other
> which are not yet reported / attempted. e.g. IPsec with L3 mode or
> even ingress routing.
And now your changes make it so that we can't run netfilter rules on
the slave's device within the slave's ns.
If someone is doing that now you're breaking things for them.
It doesn't matter whether doing so or not makes sense.
You're going to have to find a way to do both, and also I'm concerned
about how you're leaking the source namespace's "stuff" into the
destination's. That's very worrisome to me.
There is no way I'm applying this as-is, sorry.
^ permalink raw reply
* Re: [ethtool PATCH v4 10/11] ethtool.c: add support for ETHTOOL_xLINKSETTINGS ioctls
From: Ben Hutchings @ 2016-03-14 1:32 UTC (permalink / raw)
To: David Decotigny, netdev
Cc: Jeff Garzik, David Miller, Vidya Sagar Ravipati, Joe Perches,
David Decotigny
In-Reply-To: <1457719104-39188-11-git-send-email-ddecotig@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8379 bytes --]
On Fri, 2016-03-11 at 09:58 -0800, David Decotigny wrote:
[...]
> +static int parse_hex_u32_bitmap(const char *s,
> + unsigned int nbits, u32 *result)
> +{
> + const unsigned nwords = __KERNEL_DIV_ROUND_UP(nbits, 32);
> + size_t slen = strlen(s);
> + size_t i;
> +
> + /* ignore optional '0x' prefix */
> + if ((slen > 2) && (
> + (0 == memcmp(s, "0x", 2)
> + || (0 == memcmp(s, "0X", 2))))) {
memcmp() is a really poor tool for comparing strings. You should use
strncasecmp() here.
> + slen -= 2;
> + s += 2;
> + }
> +
> + if (slen > 8*nwords) /* up to 2 digits per byte */
The '*' operator should have spaces around it. Please run
checkpatch.pl over your ethtool patches to catch style errors like this
(there are many others in this one).
[...]
> +static void dump_link_caps(const char *prefix, const char *an_prefix,
> + const u32 *mask, int link_mode_only)
> {
> static const struct {
> int same_line; /* print on same line as previous */
> - u32 value;
> + unsigned bit_indice;
bit_index
[...]
> @@ -558,51 +655,57 @@ dump_link_caps(const char *prefix, const char *an_prefix, u32 mask,
> }
> }
> if (did1 == 0)
> - fprintf(stdout, "Not reported");
> + fprintf(stdout, "Not reported");
Good catch, but whitespace fixes belong in another patch.
[...]
> @@ -2248,10 +2360,219 @@ static int do_sfeatures(struct cmd_context *ctx)
> return 0;
> }
>
> -static int do_gset(struct cmd_context *ctx)
> +static struct ethtool_link_usettings *
> +__do_ioctl_glinksettings(struct cmd_context * ctx)
> +{
> + int err;
> + struct {
> + struct ethtool_link_settings req;
> + __u32 link_mode_data[3*__ETHTOOL_LINK_MODE_MASK_MAX_KERNEL_NU32];
> + } ecmd;
> + struct ethtool_link_usettings *link_usettings;
> + unsigned u32_offs;
> +
> + /* handshake with kernel to determine number of words for link
> + * mode bitmaps */
> + memset(&ecmd, 0, sizeof(ecmd));
> + ecmd.req.cmd = ETHTOOL_GLINKSETTINGS;
> + err = send_ioctl(ctx, &ecmd);
> + if (err < 0)
> + return NULL;
> +
> + if (ecmd.req.link_mode_masks_nwords >= 0 || ecmd.req.cmd)
> + return NULL;
Oops, I missed the kernel side of this. Clearing the cmd field is a
very strange thing to do and inconsistent with every other ethtool
command, so I've just sent a patch to change the kernel side of that.
You'll need to change this to match.
(I also think the negative size is a bit weird, but don't feel so
strongly about it.)
[...]
> + link_usettings = malloc(sizeof(*link_usettings));
> + if (NULL == link_usettings)
Comparison is the wrong way round.
> + return NULL;
> +
> + memset(link_usettings, 0, sizeof(*link_usettings));
Could use calloc() instead of malloc() + memset().
> + /* keep transceiver 0 */
> + memcpy(&link_usettings->base, &ecmd.req, sizeof(link_usettings->base));
> + /* remember that ETHTOOL_GLINKSETTINGS was used */
> + link_usettings->base.cmd = ETHTOOL_GLINKSETTINGS;
This is redundant as we know that ecmd.req.cmd ==
ETHTOOL_GLINKSETTINGS.
[...]
> +static struct ethtool_link_usettings *
> +__do_ioctl_gset(struct cmd_context * ctx)
> {
[...]
> + link_usettings->base.link_mode_masks_nwords = 1;
> + link_usettings->link_modes.supported[0] = ecmd.supported;
> + link_usettings->link_modes.advertising[0] = ecmd.advertising;
> + link_usettings->link_modes.lp_advertising[0] = ecmd.lp_advertising;
> + link_usettings->base.speed = ethtool_cmd_speed(&ecmd);
> + link_usettings->base.duplex = ecmd.duplex;
> + link_usettings->base.port = ecmd.port;
> + link_usettings->base.phy_address = ecmd.phy_address;
> + link_usettings->deprecated.transceiver = ecmd.transceiver;
> + link_usettings->base.autoneg = ecmd.autoneg;
> + link_usettings->base.mdio_support = ecmd.mdio_support;
> + /* ignored (fully deprecated): maxrxpkt, maxtxpkt */
> + link_usettings->base.eth_tp_mdix = ecmd.eth_tp_mdix;
> + link_usettings->base.eth_tp_mdix_ctrl = ecmd.eth_tp_mdix_ctrl;
> + link_usettings->deprecated.transceiver = ecmd.transceiver;
Duplicate assignment.
> + return link_usettings;
> +}
> +
> +static bool ethtool_link_mode_is_backward_compatible(
> + const u32 *mask)
Don't wrap function parameter lists or statements that are already
under 80 characters.
[...]
> +static void
> +__free_link_usettings(struct ethtool_link_usettings *link_usettings) {
> + free(link_usettings);
> +}
Is this function ever likely to do more than just free()? If not,
don't bother abstracting that.
[...]
> @@ -2469,75 +2799,88 @@ static int do_sset(struct cmd_context *ctx)
> }
> }
>
> - if (full_advertising_wanted < 0) {
> + if (NULL == full_advertising_wanted) {
> /* User didn't supply a full advertisement bitfield:
> * construct one from the specified speed and duplex.
> */
> + int adv_bit = -1;
> +
> if (speed_wanted == SPEED_10 && duplex_wanted == DUPLEX_HALF)
> - advertising_wanted = ADVERTISED_10baseT_Half;
> + adv_bit = ETHTOOL_LINK_MODE_10baseT_Half_BIT;
> else if (speed_wanted == SPEED_10 &&
> duplex_wanted == DUPLEX_FULL)
> - advertising_wanted = ADVERTISED_10baseT_Full;
> + adv_bit = ETHTOOL_LINK_MODE_10baseT_Full_BIT;
> else if (speed_wanted == SPEED_100 &&
> duplex_wanted == DUPLEX_HALF)
> - advertising_wanted = ADVERTISED_100baseT_Half;
> + adv_bit = ETHTOOL_LINK_MODE_100baseT_Half_BIT;
> else if (speed_wanted == SPEED_100 &&
> duplex_wanted == DUPLEX_FULL)
> - advertising_wanted = ADVERTISED_100baseT_Full;
> + adv_bit = ETHTOOL_LINK_MODE_100baseT_Full_BIT;
> else if (speed_wanted == SPEED_1000 &&
> duplex_wanted == DUPLEX_HALF)
> - advertising_wanted = ADVERTISED_1000baseT_Half;
> + adv_bit = ETHTOOL_LINK_MODE_1000baseT_Half_BIT;
> else if (speed_wanted == SPEED_1000 &&
> duplex_wanted == DUPLEX_FULL)
> - advertising_wanted = ADVERTISED_1000baseT_Full;
> + adv_bit = ETHTOOL_LINK_MODE_1000baseT_Full_BIT;
> else if (speed_wanted == SPEED_2500 &&
> duplex_wanted == DUPLEX_FULL)
> - advertising_wanted = ADVERTISED_2500baseX_Full;
> + adv_bit = ETHTOOL_LINK_MODE_2500baseX_Full_BIT;
> else if (speed_wanted == SPEED_10000 &&
> duplex_wanted == DUPLEX_FULL)
> - advertising_wanted = ADVERTISED_10000baseT_Full;
> - else
> - /* auto negotiate without forcing,
> - * all supported speed will be assigned below
> - */
> - advertising_wanted = 0;
> + adv_bit = ETHTOOL_LINK_MODE_10000baseT_Full_BIT;
> +
> + if (adv_bit >= 0) {
> + advertising_wanted = _mask_advertising_wanted;
If I'm not mistaken, _mask_advertising_wanted is uninitialised at this
point so you need to clear it before setting the one bit.
> + ethtool_link_mode_set_bit(
> + adv_bit, advertising_wanted);
[...]
> @@ -2549,37 +2892,56 @@ static int do_sset(struct cmd_context *ctx)
> fprintf(stderr, "\n");
> }
> if (autoneg_wanted == AUTONEG_ENABLE &&
> - advertising_wanted == 0) {
> + NULL == advertising_wanted) {
> + unsigned int i;
> +
> /* Auto negotiation enabled, but with
> * unspecified speed and duplex: enable all
> * supported speeds and duplexes.
> */
> - ecmd.advertising =
> - (ecmd.advertising &
> - ~ALL_ADVERTISED_MODES) |
> - (ALL_ADVERTISED_MODES & ecmd.supported);
> + ethtool_link_mode_for_each_u32(i)
> + {
Brace belongs on the previous line (everywhere you use
ethtool_link_mode_for_each_u32()).
[...]
> - } else if (advertising_wanted > 0) {
> + } else if (NULL != advertising_wanted) {
> + unsigned int i;
> +
> /* Enable all requested modes */
> - ecmd.advertising =
> - (ecmd.advertising &
> - ~ALL_ADVERTISED_MODES) |
> - advertising_wanted;
> - } else if (full_advertising_wanted > 0) {
> - ecmd.advertising = full_advertising_wanted;
> + ethtool_link_mode_for_each_u32(i)
> + {
> + u32 *adv = link_usettings->link_modes.advertising + i;
> + *adv = ((*adv & all_advertised_modes[i])
[...]
Should be ~all_advertised_modes[i] rather than all_advertised_modes[i].
Ben.
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] net: hns: add Hisilicon RoCE support
From: Yankejian (Hackim Yim) @ 2016-03-14 1:12 UTC (permalink / raw)
To: Lijun Ou, dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
jiri-VPRAkNaXOzVWk0Htik3J/w, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
gongyangming-hv44wF8Li93QT0dZR+AlfA,
xiaokun-hv44wF8Li93QT0dZR+AlfA,
tangchaofei-hv44wF8Li93QT0dZR+AlfA,
haifeng.wei-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
lisheng011-hv44wF8Li93QT0dZR+AlfA,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <20160312104301.GB15703-2ukJVAZIZ/Y@public.gmane.org>
On 2016/3/12 18:43, Leon Romanovsky wrote:
> On Fri, Mar 11, 2016 at 06:37:10PM +0800, Lijun Ou wrote:
>> It added hns_dsaf_roce_reset routine for roce driver.
>> RoCE is a feature of hns.
>> In hip06 SOC, in roce reset process, it's needed to configure
>> dsaf channel reset,port and sl map info.
>>
>> Signed-off-by: Lijun Ou <oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> Signed-off-by: Wei Hu(Xavier) <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> Signed-off-by: Lisheng <lisheng011-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> ---
>> drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 84 ++++++++++++++++++++++
>> drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h | 14 ++++
>> drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 62 +++++++++++++---
>> drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h | 13 ++++
>> 4 files changed, 163 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
>> index 38fc5be..a0f0d4f 100644
>> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
>> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
>> @@ -12,6 +12,7 @@
>> #include <linux/init.h>
>> #include <linux/interrupt.h>
>> #include <linux/netdevice.h>
>> +#include <linux/of_platform.h>
>> #include <linux/platform_device.h>
>> #include <linux/of.h>
>> #include <linux/of_address.h>
>> @@ -2593,6 +2594,89 @@ static struct platform_driver g_dsaf_driver = {
>>
>> module_platform_driver(g_dsaf_driver);
>>
>> +/**
>> + * hns_dsaf_roce_reset - reset dsaf and roce
>> + * @dsaf_fwnode: Pointer to framework node for the dasf
>> + * @val: 0 - request reset , 1 - drop reset
>> + * retuen 0 - success , negative --fail
>> + */
>> +int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, u32 val)
>> +{
>> + struct dsaf_device *dsaf_dev;
>> + struct platform_device *pdev;
>> + unsigned int mp;
>> + unsigned int sl;
>> + unsigned int credit;
>> + int i;
>> + const u32 port_map[DSAF_ROCE_CREDIT_CHN][DSAF_ROCE_CHAN_MODE] = {
>> + {0, 0, 0},
>> + {1, 0, 0},
>> + {2, 1, 0},
>> + {3, 1, 0},
>> + {4, 2, 1},
>> + {4, 2, 1},
>> + {5, 3, 1},
>> + {5, 3, 1},
>> + };
>> + const u32 sl_map[DSAF_ROCE_CREDIT_CHN][DSAF_ROCE_CHAN_MODE] = {
>> + {0, 0, 0},
>> + {0, 1, 1},
>> + {0, 0, 2},
>> + {0, 1, 3},
>> + {0, 0, 0},
>> + {1, 1, 1},
>> + {0, 0, 2},
>> + {1, 1, 3},
>> + };
> Do you have a plan to send a version with enums/defines for this
> numbers? Especially for _CHAN_MODE.
>
> .
Hi leon,
it seems the enums is added in hns_dsaf_main.h, as belows:
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
index 5fea226..c917b9a 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
@@ -40,6 +40,16 @@ struct hns_mac_cb;
#define DSAF_DUMP_REGS_NUM 504
#define DSAF_STATIC_NUM 28
+#define DSAF_ROCE_CREDIT_CHN 8
+#define DSAF_ROCE_CHAN_MODE 3
+
+enum dsaf_roce_port_port_mode {
+ DSAF_ROCE_6PORT_MODE,
+ DSAF_ROCE_4PORT_MODE,
+ DSAF_ROCE_2PORT_MODE,
+ DSAF_ROCE_CHAN_MODE_NUM
+};
+
MBR, Kejian
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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