* Re: [PATCH net-next] fq_codel: add memory limitation per queue
From: Cong Wang @ 2016-05-10 4:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Jesper Dangaard Brouer, Dave Täht, netdev,
moeller0
In-Reply-To: <1462804008.23934.30.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, May 9, 2016 at 7:26 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sun, 2016-05-08 at 22:07 -0700, Cong Wang wrote:
>> On Sun, May 8, 2016 at 9:31 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > On Sun, 2016-05-08 at 21:14 -0700, Cong Wang wrote:
>> >
>> >> So when the packet is dropped due to memory over limit, should
>> >> we return failure for this case? Or I miss anything?
>> >
>> > Same behavior than before.
>> >
>> > If we dropped some packets of this flow, we return NET_XMIT_CN
>>
>> I think for the limited memory case, the upper layer is supposed
>> to stop sending more packets when hitting the limit.
>
> They doe. NET_XMIT_CN for example aborts IP fragmentation.
>
> TCP flows will also instantly react.
But not for the NET_XMIT_SUCCESS case:
return ret == idx ? NET_XMIT_CN : NET_XMIT_SUCCESS;
^ permalink raw reply
* Re: [net-next PATCH v2 3/6] net sched: mirred action fix late binding
From: Cong Wang @ 2016-05-10 4:37 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: David Miller, Linux Kernel Network Developers
In-Reply-To: <573079DA.4020807@mojatatu.com>
On Mon, May 9, 2016 at 4:51 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 16-05-08 11:19 PM, Cong Wang wrote:
>>
>> On Sun, May 8, 2016 at 10:26 AM, Jamal Hadi Salim <jhs@mojatatu.com>
>> wrote:
>>>
>>> -static int tcf_mirred_dump(struct sk_buff *skb, struct tc_action *a, int
>>> bind, int ref)
>>> +static int tcf_mirred_dump(struct sk_buff *skb, struct tc_action *a, int
>>> bind,
>>> + int ref)
>>> {
>>> unsigned char *b = skb_tail_pointer(skb);
>>> struct tcf_mirred *m = a->priv;
>>
>>
>> Nit: this is irrelevant to the bug you fix.
>>
>
> It is (80 char) indentation fix. Dont think it deserves its own patch
> but it was annoying enough to include.
If you target this to net-next, I would not even mention it, but you
are targeting it for -stable... ;)
^ permalink raw reply
* Re: [PATCH net-next 0/5] ip6: Transmit tunneling fixes
From: David Miller @ 2016-05-10 4:39 UTC (permalink / raw)
To: alexander.duyck; +Cc: tom, netdev, kernel-team
In-Reply-To: <CAKgT0Ue_D0_nGuYQnrYfXBDdKb+ieUhZKcfnz_QxhN61mvReBw@mail.gmail.com>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Mon, 9 May 2016 20:30:46 -0700
> On Mon, May 9, 2016 at 5:12 PM, Tom Herbert <tom@herbertland.com> wrote:
>> Several fixes suggested by Alexander.
>>
>> Tested: Running netperf TCP_STREAM with gretap and keyid configured.
>> Visually verified that MTU is correctly being set. Did not test HW
>> offload (Alexander plese try)
>
> This appears to have fixed the issues I saw. I can confirm the MTU is
> the same value that it was before the regression and I am able to
> send/receive at around 17Gb/s.
>
> Tested-by: Alexander Duyck <aduyck@mirantis.com>
Series applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next] fq_codel: add memory limitation per queue
From: Eric Dumazet @ 2016-05-10 4:45 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, Jesper Dangaard Brouer, Dave Täht, netdev,
moeller0
In-Reply-To: <CAM_iQpURNs3vVVN1cceRLh2ptvsMno3bPubc9wwfQvcWe8je8g@mail.gmail.com>
On Mon, 2016-05-09 at 21:34 -0700, Cong Wang wrote:
> On Mon, May 9, 2016 at 7:26 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Sun, 2016-05-08 at 22:07 -0700, Cong Wang wrote:
> >> On Sun, May 8, 2016 at 9:31 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >> > On Sun, 2016-05-08 at 21:14 -0700, Cong Wang wrote:
> >> >
> >> >> So when the packet is dropped due to memory over limit, should
> >> >> we return failure for this case? Or I miss anything?
> >> >
> >> > Same behavior than before.
> >> >
> >> > If we dropped some packets of this flow, we return NET_XMIT_CN
> >>
> >> I think for the limited memory case, the upper layer is supposed
> >> to stop sending more packets when hitting the limit.
> >
> > They doe. NET_XMIT_CN for example aborts IP fragmentation.
> >
> > TCP flows will also instantly react.
>
> But not for the NET_XMIT_SUCCESS case:
>
> return ret == idx ? NET_XMIT_CN : NET_XMIT_SUCCESS;
I believe you missed whole point of FQ (SFQ, FQ_CODEL, FQ, ...)
If we dropped a packet of another flow because this other flow is an
elephant, why should we notify the mouse that we shot an elephant ?
We return NET_XMIT_SUCCESS because we properly queued this packet for
this flow. This is absolutely right.
If you do not like fq, just use pfifo, and yes you'll kill the mice.
^ permalink raw reply
* Re: [PATCH 0/3] Netfilter fixes for net
From: David Miller @ 2016-05-10 4:50 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1462823523-6682-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 9 May 2016 21:52:00 +0200
> The following patchset contain Netfilter simple fixes for your net tree,
> two one-liner and one two-liner:
>
> 1) Oneliner to fix missing spinlock definition that triggers
> 'BUG: spinlock bad magic on CPU#' when spinlock debugging is enabled,
> from Florian Westphal.
>
> 2) Fix missing workqueue cancelation on IDLETIMER removal,
> from Liping Zhang.
>
> 3) Fix insufficient validation of netlink of NFACCT_QUOTA in
> nfnetlink_acct, from Phil Turnbull.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH net-next] fq_codel: add memory limitation per queue
From: Cong Wang @ 2016-05-10 4:57 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Jesper Dangaard Brouer, Dave Täht, netdev,
moeller0
In-Reply-To: <1462855514.23934.51.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, May 9, 2016 at 9:45 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2016-05-09 at 21:34 -0700, Cong Wang wrote:
>> On Mon, May 9, 2016 at 7:26 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > On Sun, 2016-05-08 at 22:07 -0700, Cong Wang wrote:
>> >> On Sun, May 8, 2016 at 9:31 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> >> > On Sun, 2016-05-08 at 21:14 -0700, Cong Wang wrote:
>> >> >
>> >> >> So when the packet is dropped due to memory over limit, should
>> >> >> we return failure for this case? Or I miss anything?
>> >> >
>> >> > Same behavior than before.
>> >> >
>> >> > If we dropped some packets of this flow, we return NET_XMIT_CN
>> >>
>> >> I think for the limited memory case, the upper layer is supposed
>> >> to stop sending more packets when hitting the limit.
>> >
>> > They doe. NET_XMIT_CN for example aborts IP fragmentation.
>> >
>> > TCP flows will also instantly react.
>>
>> But not for the NET_XMIT_SUCCESS case:
>>
>> return ret == idx ? NET_XMIT_CN : NET_XMIT_SUCCESS;
>
>
> I believe you missed whole point of FQ (SFQ, FQ_CODEL, FQ, ...)
>
> If we dropped a packet of another flow because this other flow is an
> elephant, why should we notify the mouse that we shot an elephant ?
>
> We return NET_XMIT_SUCCESS because we properly queued this packet for
> this flow. This is absolutely right.
>
Sure, but we are talking about memory constraint case, aren't we?
If the whole system are suffering from memory pressure, the whole
qdisc should be halted?
^ permalink raw reply
* Re: pull-request: wireless-drivers 2016-05-09
From: David Miller @ 2016-05-10 5:03 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <8760unhwzh.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Mon, 09 May 2016 22:06:42 +0300
> one more iwlwifi fix we would like to get to 4.6 if possible. Please let
> me know if there are any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [PATCH] netfilter: conntrack: remove uninitialized shadow variable
From: David Miller @ 2016-05-10 5:04 UTC (permalink / raw)
To: arnd
Cc: pablo, kaber, kadlec, fw, daniel, sasha.levin, netfilter-devel,
coreteam, netdev, linux-kernel
In-Reply-To: <1462823254-3137116-1-git-send-email-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 9 May 2016 21:47:23 +0200
> A recent commit introduced an unconditional use of an uninitialized
> variable, as reported in this gcc warning:
>
> net/netfilter/nf_conntrack_core.c: In function '__nf_conntrack_confirm':
> net/netfilter/nf_conntrack_core.c:632:33: error: 'ctinfo' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> bytes = atomic64_read(&counter[CTINFO2DIR(ctinfo)].bytes);
> ^
> net/netfilter/nf_conntrack_core.c:628:26: note: 'ctinfo' was declared here
> enum ip_conntrack_info ctinfo;
>
> The problem is that a local variable shadows the function parameter.
> This removes the local variable, which looks like what Pablo originally
> intended.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 71d8c47fc653 ("netfilter: conntrack: introduce clash resolution on insertion race")
Applied.
^ permalink raw reply
* [PATCH V3 0/4] net-next: mediatek: improve phy support
From: John Crispin @ 2016-05-10 5:08 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, John Crispin,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, nbd-Vt+b4OUoWG0
The current driver did not handle the RGMII delay modes and asymmetric flow
control properly. The mii_bus is not freed properly. Also add support for
fixed-phy allowing the driver to work on SoCs that have an internal gigabit
switch.
John Crispin (4):
net-next: mediatek: use mdiobus_free() in favour of kfree()
net-next: mediatek: fix gigabit and flow control advertisement
net-next: mediatek: add fixed-phy support
net-next: mediatek: properly handle RGMII modes
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH V3 1/4] net-next: mediatek: use mdiobus_free() in favour of kfree()
From: John Crispin @ 2016-05-10 5:08 UTC (permalink / raw)
To: David S. Miller; +Cc: nbd, netdev, linux-mediatek, linux-kernel, John Crispin
In-Reply-To: <1462856921-27441-1-git-send-email-john@phrozen.org>
The driver currently uses kfree() to clear the mii_bus. This is not the
correct way to clear the memory and mdiobus_free() should be used instead.
This patch fixes the two instances where this happens in the driver.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: John Crispin <john@phrozen.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index c984462..28f169f 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -280,7 +280,7 @@ static int mtk_mdio_init(struct mtk_eth *eth)
return 0;
err_free_bus:
- kfree(eth->mii_bus);
+ mdiobus_free(eth->mii_bus);
err_put_node:
of_node_put(mii_np);
@@ -295,7 +295,7 @@ static void mtk_mdio_cleanup(struct mtk_eth *eth)
mdiobus_unregister(eth->mii_bus);
of_node_put(eth->mii_bus->dev.of_node);
- kfree(eth->mii_bus);
+ mdiobus_free(eth->mii_bus);
}
static inline void mtk_irq_disable(struct mtk_eth *eth, u32 mask)
--
1.7.10.4
^ permalink raw reply related
* [PATCH V3 2/4] net-next: mediatek: fix gigabit and flow control advertisement
From: John Crispin @ 2016-05-10 5:08 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, John Crispin,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, nbd-Vt+b4OUoWG0
In-Reply-To: <1462856921-27441-1-git-send-email-john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
The current code will not setup the PHYs advertisement features correctly.
Fix this and properly advertise Gigabit features and properly handle
asymmetric pause frames.
Signed-off-by: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 28f169f..a76aec20 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -133,6 +133,8 @@ static int mtk_mdio_read(struct mii_bus *bus, int phy_addr, int phy_reg)
static void mtk_phy_link_adjust(struct net_device *dev)
{
struct mtk_mac *mac = netdev_priv(dev);
+ u16 lcl_adv, rmt_adv = 0;
+ u8 flowctrl;
u32 mcr = MAC_MCR_MAX_RX_1536 | MAC_MCR_IPG_CFG |
MAC_MCR_FORCE_MODE | MAC_MCR_TX_EN |
MAC_MCR_RX_EN | MAC_MCR_BACKOFF_EN |
@@ -154,7 +156,16 @@ static void mtk_phy_link_adjust(struct net_device *dev)
mcr |= MAC_MCR_FORCE_DPX;
if (mac->phy_dev->pause)
- mcr |= MAC_MCR_FORCE_RX_FC | MAC_MCR_FORCE_TX_FC;
+ rmt_adv = LPA_PAUSE_CAP;
+ if (mac->phy_dev->asym_pause)
+ rmt_adv |= LPA_PAUSE_ASYM;
+
+ lcl_adv = mii_advertise_flowctrl(FLOW_CTRL_RX | FLOW_CTRL_TX);
+ flowctrl = mii_resolve_flowctrl_fdx(lcl_adv, rmt_adv);
+ if (flowctrl & FLOW_CTRL_TX)
+ mcr |= MAC_MCR_FORCE_TX_FC;
+ if (flowctrl & FLOW_CTRL_RX)
+ mcr |= MAC_MCR_FORCE_RX_FC;
mtk_w32(mac->hw, mcr, MTK_MAC_MCR(mac->id));
@@ -236,7 +247,8 @@ static int mtk_phy_connect(struct mtk_mac *mac)
mac->phy_dev->autoneg = AUTONEG_ENABLE;
mac->phy_dev->speed = 0;
mac->phy_dev->duplex = 0;
- mac->phy_dev->supported &= PHY_BASIC_FEATURES;
+ mac->phy_dev->supported &= PHY_GBIT_FEATURES | SUPPORTED_Pause |
+ ~SUPPORTED_Asym_Pause;
mac->phy_dev->advertising = mac->phy_dev->supported |
ADVERTISED_Autoneg;
phy_start_aneg(mac->phy_dev);
--
1.7.10.4
^ permalink raw reply related
* [PATCH V3 3/4] net-next: mediatek: add fixed-phy support
From: John Crispin @ 2016-05-10 5:08 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, John Crispin,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, nbd-Vt+b4OUoWG0
In-Reply-To: <1462856921-27441-1-git-send-email-john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
The MT7623 SoC has a builtin gigabit switch. If we want to use it, GMAC1
needs to be configured using a fixed link speed and flow control settings.
The easiest way to do this is to used the fixed-phy driver, allowing us to
reuse the existing mdio polling code to setup the MAC.
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Signed-off-by: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index a76aec20..4d59bda 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -219,6 +219,9 @@ static int mtk_phy_connect(struct mtk_mac *mac)
u32 val, ge_mode;
np = of_parse_phandle(mac->of_node, "phy-handle", 0);
+ if (!np && of_phy_is_fixed_link(mac->of_node))
+ if (!of_phy_register_fixed_link(mac->of_node))
+ np = of_node_get(mac->of_node);
if (!np)
return -ENODEV;
--
1.7.10.4
^ permalink raw reply related
* [PATCH V3 4/4] net-next: mediatek: properly handle RGMII modes
From: John Crispin @ 2016-05-10 5:08 UTC (permalink / raw)
To: David S. Miller; +Cc: nbd, netdev, linux-mediatek, linux-kernel, John Crispin
In-Reply-To: <1462856921-27441-1-git-send-email-john@phrozen.org>
If an external Gigabit PHY is connected to either of the MACs we need to
be able to tell the PHY to use a delay. Not doing so will result in heavy
packet loss and/or data corruption when using PHYs such as the IC+ IP1001.
We tell the PHY which MII delay mode to use via the devictree.
The ethernet driver needs to be adapted to handle all 3 rgmii-*id modes
in the same way as normal rgmii when setting up the MAC.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: John Crispin <john@phrozen.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 4d59bda..c5ddb4d 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -226,6 +226,9 @@ static int mtk_phy_connect(struct mtk_mac *mac)
return -ENODEV;
switch (of_get_phy_mode(np)) {
+ case PHY_INTERFACE_MODE_RGMII_TXID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII:
ge_mode = 0;
break;
--
1.7.10.4
^ permalink raw reply related
* Re: [net PATCH v2 1/1] export tc ife uapi header
From: David Miller @ 2016-05-10 5:08 UTC (permalink / raw)
To: jhs; +Cc: netdev
In-Reply-To: <1462795506-19509-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon, 9 May 2016 08:05:06 -0400
> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] fq_codel: add memory limitation per queue
From: Eric Dumazet @ 2016-05-10 5:10 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, Jesper Dangaard Brouer, Dave Täht, netdev,
moeller0
In-Reply-To: <CAM_iQpUusrr7W9diudUad+iDg3s5-4We6Z7tVzjLfMSVVJ+MMg@mail.gmail.com>
On Mon, 2016-05-09 at 21:57 -0700, Cong Wang wrote:
> Sure, but we are talking about memory constraint case, aren't we?
>
> If the whole system are suffering from memory pressure, the whole
> qdisc should be halted?
Please read the patch again.
I added a mem control, exactly to control memory usage in the first
place. If the admin allows this qdisc to consume 4MBytes, then we can
queue up to 4 Mbytes on it.
If we evict packets from _other_ flow because of whatever limit is hit
(being number of packets or memory usage), we do not report to the
innocent guy that some packets were dropped.
The innocent guy packet _is_ queued and _should_ be sent eventually.
Of course, if we could predict the future and that 456 usec later, the
packet will be lost anyway, we would notify the innocent guy right away.
But this is left for future improvement.
^ permalink raw reply
* RE: bnx2x in 4.6rc7 with FW 7.13.1.0 not present
From: Yuval Mintz @ 2016-05-10 5:22 UTC (permalink / raw)
To: Elliott, Robert (Persistent Memory)
Cc: netdev, linux-kernel, Ariel Elior, David Miller
In-Reply-To: <94D0CD8314A33A4D9D801C0FE68B4029639613DA@G4W3202.americas.hpqcorp.net>
> Upgrading a system from kernel 4.2 to 4.6rc7, there is an extra 2 minute delay
> while booting due to these problems:
>
> [ 47.977221] bnx2x 0000:04:00.1: Direct firmware load for bnx2x/bnx2x-e2-
> 7.13.1.0.fw failed with error -2
...
> Could the driver fall back to an older firmware version more gracefully?
No.
The internal FW isn't necessarily backward compatible [there are some
Compatibility in fastpath in order to support VFs, but not in general].
Doing what you ask would means filling the driver with a lot of legacy code
for older FWs, adding per-FW version HSI files, etc.
So in short - if you've installed a fresh kernel on top of an existing distro
that lacked the latest firmware in its filesystem, getting that missing
.bin file from linux-firmware is the way to go.
Cheers,
Yuval
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the wireless-drivers tree
From: Kalle Valo @ 2016-05-10 6:43 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Emmanuel Grumbach,
Sara Sharon, linux-wireless
In-Reply-To: <20160509103921.72146ce1@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/wireless/intel/iwlwifi/mvm/tx.c
>
> between commit:
>
> 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the AMSDU len")
>
> from the wireless-drivers tree and commit:
>
> d8fe484470dd ("iwlwifi: mvm: add support for new TX CMD API")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
I'm planning to fix this by merging wireless-drivers to
wireless-drivers-next later today and most likely tomorrow send a
wireless-drivers-next pull request to Dave.
--
Kalle Valo
^ permalink raw reply
* Клиентские базы тел +79133913837 (Viber, Whatsapp, Telegram) Skype: prodawez389 Email: A.b.u.r.o.v.52.@gmail.com Узнайте подробнее!
From: netdev, netdev, netdev, netdev, netdev @ 2016-05-10 0:35 UTC (permalink / raw)
To: netdev, netdev, netdev, netdev, netdev
Клиентские базы тел +79133913837 (Viber, Whatsapp, Telegram) Skype: prodawez389 Email: aburov52@gmail.com
Соберем для Вас по интернет базу данных потенциальных клиентов для вашего Бизнеса!
Все контактные данные! Много! Быстро! Недорого! Узнайте подробнее:
тел +79133913837 (Viber, Whatsapp, Telegram)
Skype: prodawez389
Email: aburov52@gmail.com
^ permalink raw reply
* ax88179_178a: disabled FLAG_MULTI_PACKET
From: Vivek Bhagat @ 2016-05-10 7:35 UTC (permalink / raw)
To: netdev
Hi,
ax88179_178a_rx_fixup() function is cloning the data and calling
usbnet_skb_return(). Since FLAG_MULTI_PACKET is not set,
usbnet_skb_return() is being called second time within rx_process()
function in usbnet.c.
I simply enabled the flag in ax88179_info as below -
.flags = FLAG_ETHER..| FLAG_MULTI_PACKET
Ping stops working.
Could anyone please point out what could be the reason behind sending
same packets 2 times to upper layer (from usbnet and its class driver
ax88179_178a)?
In case of asix 2.0 driver, avove flag is set and it is working.
Thanks,
Vivek
^ permalink raw reply
* Re: [PATCH net-next V3 00/10] cls_flower hardware offload support
From: Or Gerlitz @ 2016-05-10 7:37 UTC (permalink / raw)
To: David Miller
Cc: Amir Vadai, Linux Netdev List, John Fastabend, Saeed Mahameed,
Jiri Pirko
In-Reply-To: <20160509.211435.166413633642228166.davem@davemloft.net>
On Tue, May 10, 2016 at 4:14 AM, David Miller <davem@davemloft.net> wrote:
> From: Or Gerlitz <gerlitz.or@gmail.com>
> Date: Mon, 9 May 2016 23:31:52 +0300
>> Wanted to check with you if such a submission can take place in
>> parallel with another net-next mlx5 only submission which is planned
>> by the driver team.
> One series at a time please.
Okay, since the driver-only series is three patches, will put all in
one series,
such that it'e ensured no conflicts and such.
Or.
^ permalink raw reply
* Re: [PATCH net-next v3] block/drbd: align properly u64 in nl messages
From: Nicolas Dichtel @ 2016-05-10 9:09 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160509131547.GX16459-w1SgEEioFePxa46PmUWvFg@public.gmane.org>
Le 09/05/2016 15:15, Lars Ellenberg a écrit :
> On Mon, May 09, 2016 at 11:40:20AM +0200, Nicolas Dichtel wrote:
[snip]
>> Maybe prefixing genl_magic_func.h and genl_magic_struct.h by 'drbd_'
>> could be interesting so that new module won't use it. What is your
>> opinion?
>
> This was supposed to not be DRBD specific. But it might even still
> need some massaging before it was truly generic. And obviously,
> it does not meet the taste of genetlink folks, to say the least :(
Yes, this file is not generic and netlink APIs are never defined like this.
These tons of macro complexifies the code too much. It's overengineering for
what purpose?
Small examples:
- the drbd netlink API is not exported via uapi (I wonder how apps using this
API get it)
- v2 of the patch is nacked because adding a new attribute may break existing
apps (in networking code, a lot of new attributes are added in each version)
- it's not possible to grep to show the definition of an attribute ('git grep
-w T_bits_total' returns only 1 line)
Regards,
Nicolas
^ permalink raw reply
* Re: [net-next PATCH V1 1/3] net: bulk alloc and reuse of SKBs in NAPI context
From: Jesper Dangaard Brouer @ 2016-05-10 9:29 UTC (permalink / raw)
To: Alexander Duyck
Cc: Netdev, David S. Miller, Saeed Mahameed, Or Gerlitz,
Eugenia Emantayev, brouer
In-Reply-To: <CAKgT0UfKzKWnNzGpB-915by2M1nzDAdNz-hDwwcwGoowmZefrg@mail.gmail.com>
On Mon, 9 May 2016 13:46:32 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:
> > As you also know, tuning the SLUB system will give higher performance,
> > easily. In the future, I'm planning to get some auto-tuning into the
> > SLUB allocator. I've already discussed this with Christiph Lameter, at
> > MM-summit, see presentation[1] slides 4 and 5.
>
> We aren't discussing tuning parameters. We are discussing this patch.
> If you want to argue that with certain tuning parameters this shows
> more performance then bring the numbers, but don't try to bias things.
> If you have to tune the system in some way that nobody will there is
> probably no point in submitting the patch because nobody will use it
> that way.
I think you missed the point. I didn't do parameter tuning for my
benchmarks. I hate tuning parameters, they are huge problem for users
of the kernel.
My point is that I want to implement auto-tuning in the SLUB
allocator. This network stack use-case, will just be one use-case
where the auto-tuning need to show improvements. It is not that
complicated. FreeBSD have this kind of auto-tuning to the workload in
their slab implementation.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Password Reset update
From: mmacgregor0923 @ 2016-05-10 9:25 UTC (permalink / raw)
To: infO@mail.org
Your e-mailbox password will soon expire. To keep your password active. Click Here<http://cm143.jimdo.com/> to update
IT- Desk
^ permalink raw reply
* Re: [PATCH net-next v3] block/drbd: align properly u64 in nl messages
From: Lars Ellenberg @ 2016-05-10 9:40 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, drbd-dev-cunTk1MwBs8qoQakbn7OcQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA
In-Reply-To: <5731A561.6090509-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
On Tue, May 10, 2016 at 11:09:53AM +0200, Nicolas Dichtel wrote:
> Le 09/05/2016 15:15, Lars Ellenberg a écrit :
> > On Mon, May 09, 2016 at 11:40:20AM +0200, Nicolas Dichtel wrote:
> [snip]
> >> Maybe prefixing genl_magic_func.h and genl_magic_struct.h by 'drbd_'
> >> could be interesting so that new module won't use it. What is your
> >> opinion?
> >
> > This was supposed to not be DRBD specific. But it might even still
> > need some massaging before it was truly generic. And obviously,
> > it does not meet the taste of genetlink folks, to say the least :(
> Yes, this file is not generic and netlink APIs are never defined like this.
> These tons of macro complexifies the code too much. It's overengineering for
> what purpose?
If we introduce a new config option,
we have to add it to the config scanner (one line),
define min, max, default and scale (four short defines),
and add it to the netlink definition here (one line).
Done, rest of the code is generated,
both on the kernel side,
and on the drbd-utils side used to talk to the kernel.
We found that to be very convenient.
> Small examples:
> - the drbd netlink API is not exported via uapi (I wonder how apps using this
> API get it)
There used to be a time where there was no "uapi".
(I wonder how apps ever worked back then).
> - v2 of the patch is nacked because adding a new attribute may break existing
No.
But because the "new" attributes you chose have not been new,
but already used (though not yet merged back into mainline yet).
(Which you did not realize, and had no obvious way of knowing.
Could have been fixed.).
And because your patch introduced useless new members to the structs.
(Could also have been fixed).
And because I did not see any use defining that many new "padding attributes"
for no reason, where the obvious (to me) choice was to use 0, and you
did not even try to explain why that would have been a bad choice.
> apps (in networking code, a lot of new attributes are added in each version)
> - it's not possible to grep to show the definition of an attribute ('git grep
> -w T_bits_total' returns only 1 line)
Opencoded, it would return 2.
;-)
Is this going somewhere?
Cheers,
Lars
^ permalink raw reply
* [PATCH net-next v2] ila: ipv6/ila: fix nlsize calculation for lwtunnel
From: Nicolas Dichtel @ 2016-05-10 9:56 UTC (permalink / raw)
To: tom; +Cc: netdev, davem, Nicolas Dichtel
In-Reply-To: <20160501.193926.994161705403597197.davem@davemloft.net>
From: Tom Herbert <tom@herbertland.com>
The handler 'ila_fill_encap_info' adds two attributes: ILA_ATTR_LOCATOR
and ILA_ATTR_CSUM_MODE.
nla_total_size_64bit() must be use for ILA_ATTR_LOCATOR.
Also, do nla_put_u8 instead of nla_put_u64 for ILA_ATTR_CSUM_MODE.
Fixes: f13a82d87b21 ("ipv6: use nla_put_u64_64bit()")
Fixes: 90bfe662db13 ("ila: add checksum neutral ILA translations")
Reported-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Tom Herbert <tom@herbertland.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
Tom, I have taken the liberty of resending your patch, I hope it's ok
for you. Goal is to fix this before net-next closes.
v1 -> v2:
update the patch after the merge of net (and thus update 'Fixes' tag)
use nla_total_size_64bit() for ILA_ATTR_LOCATOR
net/ipv6/ila/ila_lwt.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ila/ila_lwt.c b/net/ipv6/ila/ila_lwt.c
index 17038e1ede98..1dfb64166d7d 100644
--- a/net/ipv6/ila/ila_lwt.c
+++ b/net/ipv6/ila/ila_lwt.c
@@ -133,7 +133,7 @@ static int ila_fill_encap_info(struct sk_buff *skb,
if (nla_put_u64_64bit(skb, ILA_ATTR_LOCATOR, (__force u64)p->locator.v64,
ILA_ATTR_PAD))
goto nla_put_failure;
- if (nla_put_u64(skb, ILA_ATTR_CSUM_MODE, (__force u8)p->csum_mode))
+ if (nla_put_u8(skb, ILA_ATTR_CSUM_MODE, (__force u8)p->csum_mode))
goto nla_put_failure;
return 0;
@@ -144,7 +144,9 @@ nla_put_failure:
static int ila_encap_nlsize(struct lwtunnel_state *lwtstate)
{
- return nla_total_size(sizeof(u64)); /* ILA_ATTR_LOCATOR */
+ return nla_total_size_64bit(sizeof(u64)) + /* ILA_ATTR_LOCATOR */
+ nla_total_size(sizeof(u8)) + /* ILA_ATTR_CSUM_MODE */
+ 0;
}
static int ila_encap_cmp(struct lwtunnel_state *a, struct lwtunnel_state *b)
--
2.8.1
^ 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