* RE: [PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver
From: Yuval Mintz @ 2017-10-15 8:51 UTC (permalink / raw)
To: Yunsheng Lin, davem@davemloft.net
Cc: huangdaode@hisilicon.com, xuwei5@hisilicon.com,
liguozhu@hisilicon.com, Yisen.Zhuang@huawei.com,
gabriele.paoloni@huawei.com, john.garry@huawei.com,
linuxarm@huawei.com, salil.mehta@huawei.com, lipeng321@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
amritha.nambiar@intel.com
In-Reply-To: <AM0PR0502MB368336C6A93618A13ADBB68ABF4E0@AM0PR0502MB3683.eurprd05.prod.outlook.com>
> > >> This patchset adds a new hardware offload type in mqprio before
> adding
> > >> mqprio hardware offload support in hns3 driver.
Apparently Dave has already accepted Amirtha's changes to mqprio:
https://marc.info/?l=linux-netdev&m=150803219824053&w=2
so I guess you need to revise your patchs to align to the new conventions.
> > >
> > > I think one of the biggest issues in tying this to DCB configuration is the
> > > non-immediate [and possibly non persistent] configuration.
> > >
> > > Scenario #1:
> > > User is configuring mqprio offloaded with 3 TCs while device is in willing
> > mode.
> > > Would you expect the driver to immediately respond with a success or
> > instead
> > > delay the return until the DCBx negotiation is complete and the
> operational
> > > num of TCs is actually 3?
> >
> > Well, when user requsts the mqprio offloaded by a hardware shared by
> DCB,
> > I expect
> > the user is not using the dcb tool.
> > If user is still using dcb tool, then result is undefined.
> >
> > The scenario you mention maybe can be enforced by setting willing to zero
> > when user
> > is requesting the mqprio offload, and restore the willing bit when unloaded
> > the mqprio
> > offload.
>
> Sounds a bit harsh but would probably work.
>
> > But I think the real issue is that dcb and mqprio shares the tc system in the
> > stack,
> > the problem may be better to be fixed in the stack rather than in the
> driver,
> > as you
> > suggested in the DCB patchset. What do you think?
>
> What did you have in mind?
>
> >
> > >
> > > Scenario #2:
> > > Assume user explicitly offloaded mqprio with 3 TCs, but now DCB
> > configuration
> > > has changed on the peer side and 4 TCs is the new negotiated operational
> > value.
> > > Your current driver logic would change the number of TCs underneath
> the
> > user
> > > configuration [and it would actually probably work due to mqprio being a
> > crappy
> > > qdisc]. But was that the user actual intention?
> > > [I think the likely answer in this scenario is 'yes' since the alternative is no
> > better.
> > > But I still thought it was worth mentioning]
> >
> > You are right, the problem also have something to do with mqprio and dcb
> > sharing
> > the tc in the stack.
> >
> > Druing testing, when user explicitly offloaded mqprio with 3 TCs, all
> > queue has a default pfifo mqprio attached, after DCB changes the tc num
> to
> > 4,
> > using tc qdisc shows some queue does not have a default pfifo mqprio
> > attached.
>
> Really? Then what did it show?
> [I assume it has some pfifo attached, and it's an mqprio dump kind of an
> issue]
>
> >
> > Maybe we can add a callback to notify mqprio the configuration has
> changed.
> >
>
> Which would do what?
> You already have the notifications available for monitoring using dcbnl logic if
> the
> configuration change [for user]; So user can re-configure whatever it wants.
> But other than dropping all the qdisc configurations and going back to the
> default
> qdiscs, what default action would mqprio be able to do when configuration
> changes
> that actually makes sense?
>
> > Thanks
> > Yunsheng Lin
> >
> > >
> > > Cheers,
> > > Yuval
> > >
> > >>
> > >> Yunsheng Lin (2):
> > >> mqprio: Add a new hardware offload type in mqprio
> > >> net: hns3: Add mqprio hardware offload support in hns3 driver
> > >>
> > >> drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 +
> > >> .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++++++++++
> > >> .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46
> > ++++++++++++++-
> > >> -------
> > >> include/uapi/linux/pkt_sched.h | 1 +
> > >> 4 files changed, 55 insertions(+), 16 deletions(-)
> > >>
> > >> --
> > >> 1.9.1
> > >
> > >
> > >
^ permalink raw reply
* Re: [PATCH net-next 4/5] mlxsw: spectrum: router: Add support for address validator notifier
From: Ido Schimmel @ 2017-10-15 8:36 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, jiri, idosch, kjlx, davem, yoshfuji
In-Reply-To: <1507935733-18950-5-git-send-email-dsahern@gmail.com>
On Fri, Oct 13, 2017 at 04:02:12PM -0700, David Ahern wrote:
> Add support for inetaddr_validator and inet6addr_validator. The
> notifiers provide a means for validating ipv4 and ipv6 addresses
> before the addresses are installed and on failure the error
> is propagated back to the user.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Thanks!
^ permalink raw reply
* Re: [PATCH net-next 2/5] net: ipv6: Make inet6addr_validator a blocking notifier
From: Ido Schimmel @ 2017-10-15 7:53 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, jiri, idosch, kjlx, davem, yoshfuji
In-Reply-To: <1507935733-18950-3-git-send-email-dsahern@gmail.com>
On Fri, Oct 13, 2017 at 04:02:10PM -0700, David Ahern wrote:
> inet6addr_validator chain was added by commit 3ad7d2468f79f ("Ipvlan
> should return an error when an address is already in use") to allow
> address validation before changes are committed and to be able to
> fail the address change with an error back to the user. The address
> validation is not done for addresses received from router
> advertisements.
>
> Handling RAs in softirq context is the only reason for the notifier
> chain to be atomic versus blocking. Since the only current user, ipvlan,
> of the validator chain ignores softirq context, the notifier can be made
> blocking and simply not invoked for softirq path.
>
> The blocking option is needed by spectrum for example to validate
> resources for an adding an address to an interface.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Thanks for taking care of the in_softirq() check.
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 1/5] ipv6: addrconf: cleanup locking in ipv6_add_addr
From: Ido Schimmel @ 2017-10-15 7:50 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, jiri, idosch, kjlx, davem, yoshfuji
In-Reply-To: <1507935733-18950-2-git-send-email-dsahern@gmail.com>
On Fri, Oct 13, 2017 at 04:02:09PM -0700, David Ahern wrote:
> ipv6_add_addr is called in process context with rtnl lock held
> (e.g., manual config of an address) or during softirq processing
> (e.g., autoconf and address from a router advertisement).
>
> Currently, ipv6_add_addr calls rcu_read_lock_bh shortly after entry
> and does not call unlock until exit, minus the call around the address
> validator notifier. Similarly, addrconf_hash_lock is taken after the
> validator notifier and held until exit. This forces the allocation of
> inet6_ifaddr to always be atomic.
>
> Refactor ipv6_add_addr as follows:
> 1. add an input boolean to discriminate the call path (process context
> or softirq). This new flag controls whether the alloc can be done
> with GFP_KERNEL or GFP_ATOMIC.
>
> 2. Move the rcu_read_lock_bh and unlock calls only around functions that
> do rcu updates.
>
> 3. Remove the in6_dev_hold and put added by 3ad7d2468f79f ("Ipvlan should
> return an error when an address is already in use."). This was done
> presumably because rcu_read_unlock_bh needs to be called before calling
> the validator. Since rcu_read_lock is not needed before the validator
> runs revert the hold and put added by 3ad7d2468f79f and only do the
> hold when setting ifp->idev.
>
> 4. move duplicate address check and insertion of new address in the global
> address hash into a helper. The helper is called after an ifa is
> allocated and filled in.
>
> This allows the ifa for manually configured addresses to be done with
> GFP_KERNEL and reduces the overall amount of time with rcu_read_lock held
> and hash table spinlock held.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
[...]
> @@ -1073,21 +1085,19 @@ ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr,
>
> in6_ifa_hold(ifa);
> write_unlock(&idev->lock);
> -out2:
> +
> rcu_read_unlock_bh();
>
> - if (likely(err == 0))
> - inet6addr_notifier_call_chain(NETDEV_UP, ifa);
> - else {
> + inet6addr_notifier_call_chain(NETDEV_UP, ifa);
> +out:
> + if (unlikely(err < 0)) {
> + if (rt)
> + ip6_rt_put(rt);
I believe 'rt' needs to be set to NULL after addrconf_dst_alloc()
fails.
> kfree(ifa);
> - in6_dev_put(idev);
> ifa = ERR_PTR(err);
> }
>
> return ifa;
> -out:
> - spin_unlock(&addrconf_hash_lock);
> - goto out2;
> }
^ permalink raw reply
* Re: [patch net-next 06/34] net: core: use dev->ingress_queue instead of tp->q
From: Jiri Pirko @ 2017-10-15 6:45 UTC (permalink / raw)
To: Daniel Borkmann
Cc: netdev, davem, jhs, xiyou.wangcong, mlxsw, andrew, vivien.didelot,
f.fainelli, michael.chan, ganeshgr, jeffrey.t.kirsher, saeedm,
matanb, leonro, idosch, jakub.kicinski, ast, simon.horman,
pieter.jansenvanvuuren, john.hurley, edumazet, dsahern,
alexander.h.duyck, john.fastabend, willemb
In-Reply-To: <59E29B5E.9000304@iogearbox.net>
Sun, Oct 15, 2017 at 01:18:54AM CEST, daniel@iogearbox.net wrote:
>On 10/13/2017 08:30 AM, Jiri Pirko wrote:
>> Thu, Oct 12, 2017 at 11:45:43PM CEST, daniel@iogearbox.net wrote:
>> > On 10/12/2017 07:17 PM, Jiri Pirko wrote:
>> > > From: Jiri Pirko <jiri@mellanox.com>
>> > >
>> > > In sch_handle_egress and sch_handle_ingress, don't use tp->q and use
>> > > dev->ingress_queue which stores the same pointer instead.
>> > >
>> > > Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>> > > ---
>> > > net/core/dev.c | 21 +++++++++++++++------
>> > > 1 file changed, 15 insertions(+), 6 deletions(-)
>> > >
>> > > diff --git a/net/core/dev.c b/net/core/dev.c
>> > > index fcddccb..cb9e5e5 100644
>> > > --- a/net/core/dev.c
>> > > +++ b/net/core/dev.c
>> > > @@ -3273,14 +3273,18 @@ EXPORT_SYMBOL(dev_loopback_xmit);
>> > > static struct sk_buff *
>> > > sch_handle_egress(struct sk_buff *skb, int *ret, struct net_device *dev)
>> > > {
>> > > + struct netdev_queue *netdev_queue =
>> > > + rcu_dereference_bh(dev->ingress_queue);
>> > > struct tcf_proto *cl = rcu_dereference_bh(dev->egress_cl_list);
>> > > struct tcf_result cl_res;
>> > > + struct Qdisc *q;
>> > >
>> > > - if (!cl)
>> > > + if (!cl || !netdev_queue)
>> > > return skb;
>> > > + q = netdev_queue->qdisc;
>> >
>> > NAK, no additional overhead in the software fast-path of
>> > sch_handle_{ingress,egress}() like this. There are users out there
>> > that use tc in software only, so performance is critical here.
>>
>> Okay, how else do you suggest I can avoid the need to use tp->q?
>> I was thinking about storing q directly to net_device, which would safe
>> one dereference, resulting in the same amount as current cl->q.
>
>Sorry for late reply, mostly off for few days. netdev struct has different
>cachelines which are hot on rx and tx (see also the location of the two
>lists, ingress_cl_list and egress_cl_list), if you add only one qdisc
>pointer there, then you'd at least penalize one of the two w/ potential
>cache miss. Can we leave it in cl?
Well that is the whole point of this excercise, to remove it from cl.
The thing is, for the shared blocks, cls are shared between multiple
qdisc instances, so cl->q makes no longer any sense.
^ permalink raw reply
* Re: [pull request][for-next 00/12] Mellanox, mlx5 IPoIB Muli Pkey support 2017-10-11
From: Leon Romanovsky @ 2017-10-15 6:30 UTC (permalink / raw)
To: Doug Ledford; +Cc: Saeed Mahameed, David S. Miller, netdev, linux-rdma
In-Reply-To: <af28440c-bb1c-c47b-92dd-60bfbeaa839d@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
On Sat, Oct 14, 2017 at 05:19:34PM -0400, Doug Ledford wrote:
> On 10/14/2017 2:48 PM, Saeed Mahameed wrote:
> > Hi Dave and Doug,
> >
> > This series includes updates for mlx5 IPoIB offloading driver from Alex
> > and Feras to add the support for Muli Pkey in the mlx5i ipoib offloading netdev,
> > to be merged into net-next and rdma-next trees.
>
> As far as the two IPoIB patches are concerned, they're fine.
>
> > Doug, I am sorry I couldn't base this on rc2 since the series needs and conflicts
> > with a fix that was submitted to rc3, so to keep things simple I based it on rc4,
> > I hope this is ok with you..
>
> No worries, it just means I have to submit it under another branch. But
> I'm already holding one patch series in a stand alone branch, so no big
> deal. And, actually, the IPoIB changes are so small they can simply go
> through Dave's tree if you don't have any dependent code in the IPoIB
> driver to submit after this but still in this devel cycle.
I have IPoIB NAPI implementation waiting for this shared code.
Thanks
>
> > Please pull and let me know if there's any problem.
>
> Once I hear that Dave is OK with the net changes, I'm ready to pull (if
> I need to).
>
> --
> Doug Ledford <dledford@redhat.com>
> GPG Key ID: B826A3330E572FDD
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver
From: Yuval Mintz @ 2017-10-15 5:14 UTC (permalink / raw)
To: Yunsheng Lin, davem@davemloft.net
Cc: huangdaode@hisilicon.com, xuwei5@hisilicon.com,
liguozhu@hisilicon.com, Yisen.Zhuang@huawei.com,
gabriele.paoloni@huawei.com, john.garry@huawei.com,
linuxarm@huawei.com, salil.mehta@huawei.com, lipeng321@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <5c268e80-3b04-28bd-26fb-d77f2edd69a8@huawei.com>
> Hi, Yuval
>
> On 2017/10/13 4:21, Yuval Mintz wrote:
> >> This patchset adds a new hardware offload type in mqprio before adding
> >> mqprio hardware offload support in hns3 driver.
> >
> > I think one of the biggest issues in tying this to DCB configuration is the
> > non-immediate [and possibly non persistent] configuration.
> >
> > Scenario #1:
> > User is configuring mqprio offloaded with 3 TCs while device is in willing
> mode.
> > Would you expect the driver to immediately respond with a success or
> instead
> > delay the return until the DCBx negotiation is complete and the operational
> > num of TCs is actually 3?
>
> Well, when user requsts the mqprio offloaded by a hardware shared by DCB,
> I expect
> the user is not using the dcb tool.
> If user is still using dcb tool, then result is undefined.
>
> The scenario you mention maybe can be enforced by setting willing to zero
> when user
> is requesting the mqprio offload, and restore the willing bit when unloaded
> the mqprio
> offload.
Sounds a bit harsh but would probably work.
> But I think the real issue is that dcb and mqprio shares the tc system in the
> stack,
> the problem may be better to be fixed in the stack rather than in the driver,
> as you
> suggested in the DCB patchset. What do you think?
What did you have in mind?
>
> >
> > Scenario #2:
> > Assume user explicitly offloaded mqprio with 3 TCs, but now DCB
> configuration
> > has changed on the peer side and 4 TCs is the new negotiated operational
> value.
> > Your current driver logic would change the number of TCs underneath the
> user
> > configuration [and it would actually probably work due to mqprio being a
> crappy
> > qdisc]. But was that the user actual intention?
> > [I think the likely answer in this scenario is 'yes' since the alternative is no
> better.
> > But I still thought it was worth mentioning]
>
> You are right, the problem also have something to do with mqprio and dcb
> sharing
> the tc in the stack.
>
> Druing testing, when user explicitly offloaded mqprio with 3 TCs, all
> queue has a default pfifo mqprio attached, after DCB changes the tc num to
> 4,
> using tc qdisc shows some queue does not have a default pfifo mqprio
> attached.
Really? Then what did it show?
[I assume it has some pfifo attached, and it's an mqprio dump kind of an issue]
>
> Maybe we can add a callback to notify mqprio the configuration has changed.
>
Which would do what?
You already have the notifications available for monitoring using dcbnl logic if the
configuration change [for user]; So user can re-configure whatever it wants.
But other than dropping all the qdisc configurations and going back to the default
qdiscs, what default action would mqprio be able to do when configuration changes
that actually makes sense?
> Thanks
> Yunsheng Lin
>
> >
> > Cheers,
> > Yuval
> >
> >>
> >> Yunsheng Lin (2):
> >> mqprio: Add a new hardware offload type in mqprio
> >> net: hns3: Add mqprio hardware offload support in hns3 driver
> >>
> >> drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 +
> >> .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++++++++++
> >> .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46
> ++++++++++++++-
> >> -------
> >> include/uapi/linux/pkt_sched.h | 1 +
> >> 4 files changed, 55 insertions(+), 16 deletions(-)
> >>
> >> --
> >> 1.9.1
> >
> >
> >
^ permalink raw reply
* Re: [net-next 3/3] tcp: keep tcp_collapse controllable even after processing starts
From: Koichiro Den @ 2017-10-15 2:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, kuznet, yoshfuji
In-Reply-To: <1507995970.31614.59.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 2017-10-14 at 08:46 -0700, Eric Dumazet wrote:
> On Sat, 2017-10-14 at 16:27 +0900, Koichiro Den wrote:
> > Combining actual collapsing with reasoning for deciding the starting
> > point, we can apply its logic in a consistent manner such that we can
> > avoid costly yet not much useful collapsing. When collapsing to be
> > triggered, it's not rare that most of the skbs in the receive or ooo
> > queue are large ones without much metadata overhead. This also
> > simplifies code and makes it easier to apply logic in a fair manner.
> >
> > Subtle subsidiary changes included:
> > - When the end_seq of the skb we are trying to collapse was larger than
> > the 'end' argument provided, we would end up copying to the 'end'
> > even though we couldn't collapse the original one. Current users of
> > tcp_collapse does not require such reserves so redefines it as the
> > point over which skbs whose seq passes guranteed not to be collapsed.
> > - Naturally tcp_collapse_ofo_queue shapes up and we no longer need
> > 'tail' argument.
>
>
> I am not inclined to review such a large change, without you providing
> actual numbers.
>
> We have a problem in TCP right now, that receiver announces a too big
> window, and that is the main reason we trigger collapsing.
>
> I would rather fix the root cause.
>
>
Ok I got it, thank you.
^ permalink raw reply
* Re: [net-next 2/3] tcp: do not tcp_collapse once SYN or FIN found
From: Koichiro Den @ 2017-10-15 2:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, kuznet, yoshfuji
In-Reply-To: <1507995823.31614.57.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 2017-10-14 at 08:43 -0700, Eric Dumazet wrote:
> On Sat, 2017-10-14 at 16:27 +0900, Koichiro Den wrote:
> > Since 9f5afeae5152 ("tcp: use an RB tree for ooo receive queue")
> > applied, we no longer need to continue to search for the starting
> > point once we encounter FIN packet. Same reasoning for SYN packet
> > since commit 9d691539eea2d ("tcp: do not enqueue skb with SYN flag"),
> > that would help us with error message when actual receiving.
>
> Very confusing changelog or patch.
>
> What exact problem do you want to solve ?
>
>
That I thought as unnecessary search for the starting point. I am going to re-
read all to correct my misunderstanding.
Thank you.
^ permalink raw reply
* Re: [net-next 1/3] tcp: avoid useless copying and collapsing of just one skb
From: Koichiro Den @ 2017-10-15 2:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, kuznet, yoshfuji
In-Reply-To: <1507995761.31614.56.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 2017-10-14 at 08:42 -0700, Eric Dumazet wrote:
> On Sat, 2017-10-14 at 16:27 +0900, Koichiro Den wrote:
> > On the starting point chosen, it could be possible that just one skb
> > remains in between the range provided, leading to copying and re-insertion
> > of rb node, which is useless with respect to the rcv buf measurement.
> > This is rather probable in ooo queue case, in which non-contiguous bloated
> > packets have been queued up.
> >
> > Signed-off-by: Koichiro Den <den@klaipeden.com>
> > ---
> > net/ipv4/tcp_input.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> > index d0682ce2a5d6..1d785b5bf62d 100644
> > --- a/net/ipv4/tcp_input.c
> > +++ b/net/ipv4/tcp_input.c
> > @@ -4807,7 +4807,8 @@ tcp_collapse(struct sock *sk, struct sk_buff_head
> > *list, struct rb_root *root,
> > start = TCP_SKB_CB(skb)->end_seq;
> > }
> > if (end_of_skbs ||
> > - (TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)))
> > + (TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)) ||
> > + (TCP_SKB_CB(skb)->seq == start && TCP_SKB_CB(skb)->end_seq ==
> > end))
> > return;
> >
> > __skb_queue_head_init(&tmp);
>
>
> What do you mean by useless ?
>
> Surely if this skb contains 17 segments (some USB drivers allocate 8KB
> per frame), we want to collapse them to save memory.
>
> So I do not agree with this patch.
>
>
I missed that, and sorry about bothering with all, I totally misunderstood it.
Thank you for all of them.
^ permalink raw reply
* [PATCH] rtlwifi: Fix typo in if ... else if ... else construct
From: Larry Finger @ 2017-10-15 1:58 UTC (permalink / raw)
To: gregkh
Cc: netdev, devel, Larry Finger, Ping-Ke Shih, Yan-Hsuan Chuang,
Birming Chiu, Shaofu, Steven Ting, kbuild-all, Julia Lawall
The kbuild test robot reports two conditions with no effect (if == else).
These are the result of copy and paste typographical errors.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Cc: kbuild-all@01.org
Cc: Julia Lawall <julia.lawall@lip6.fr>
---
drivers/staging/rtlwifi/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
index b88b0e8edd3d..1a0331cf63ee 100644
--- a/drivers/staging/rtlwifi/base.c
+++ b/drivers/staging/rtlwifi/base.c
@@ -920,7 +920,7 @@ static u8 _rtl_get_vht_highest_n_rate(struct ieee80211_hw *hw,
else if ((tx_mcs_map & 0x000c) >> 2 ==
IEEE80211_VHT_MCS_SUPPORT_0_8)
hw_rate =
- rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS9];
+ rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS8];
else
hw_rate =
rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS9];
@@ -932,7 +932,7 @@ static u8 _rtl_get_vht_highest_n_rate(struct ieee80211_hw *hw,
else if ((tx_mcs_map & 0x0003) ==
IEEE80211_VHT_MCS_SUPPORT_0_8)
hw_rate =
- rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS9];
+ rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS8];
else
hw_rate =
rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS9];
--
2.12.3
^ permalink raw reply related
* Re: [PATCH net 0/6] bnxt_en: bug fixes.
From: David Miller @ 2017-10-15 1:52 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1507943374-13308-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Fri, 13 Oct 2017 21:09:28 -0400
> Various bug fixes for the VF/PF link change logic, VF resource checking,
> potential firmware response corruption on NVRAM and DCB parameters,
> and reading the wrong register for PCIe link speed on the VF.
Series applied, thanks.
^ permalink raw reply
* Re: [net-next 0/9][pull request] 40GbE Intel Wired LAN Driver Updates 2017-10-13
From: David Miller @ 2017-10-15 1:49 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20171013215249.61286-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 13 Oct 2017 14:52:40 -0700
> This series contains updates to mqprio and i40e.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] tc-testing: Test suite updates
From: David Miller @ 2017-10-15 1:48 UTC (permalink / raw)
To: lucasb; +Cc: netdev, xiyou.wangcong, jiri, jhs, aring, mrv
In-Reply-To: <1507931485-1814-1-git-send-email-lucasb@mojatatu.com>
From: Lucas Bates <lucasb@mojatatu.com>
Date: Fri, 13 Oct 2017 17:51:21 -0400
> This patch series is a roundup of changes to the tc-testing
> suite:
>
> - Add test cases for police and mirred modules and some coverage
> in already-submitted test categories
> - Break the test case files down into more user-friendly sizes
> - Bug fix to the tdc.py script's handling of the -l argument
>
> v2: fix the lack of final newlines in two new files (thanks David)
Series applied, thanks for fixing that up.
^ permalink raw reply
* Re: [net-next PATCH 0/2] Minor macvlan source mode cleanups
From: David Miller @ 2017-10-15 1:46 UTC (permalink / raw)
To: alexander.duyck; +Cc: netdev
In-Reply-To: <20171013203726.16950.32584.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Fri, 13 Oct 2017 13:40:18 -0700
> So this patch series is just a few minor cleanups for macvlan source mode.
> The first patch addresses double receives when a packet is being routed to
> the macvlan destination address, and the other addresses the pkt_type being
> updated in cases where it most likely should not be.
Series applied, thanks.
^ permalink raw reply
* Re: [Patch net-next v3] tcp: add a tracepoint for tcp retransmission
From: David Miller @ 2017-10-15 1:45 UTC (permalink / raw)
To: xiyou.wangcong
Cc: netdev, edumazet, alexei.starovoitov, hannes, brendan.d.gregg,
ncardwell
In-Reply-To: <20171013200316.28561-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 13 Oct 2017 13:03:16 -0700
> We need a real-time notification for tcp retransmission
> for monitoring.
>
> Of course we could use ftrace to dynamically instrument this
> kernel function too, however we can't retrieve the connection
> information at the same time, for example perf-tools [1] reads
> /proc/net/tcp for socket details, which is slow when we have
> a lots of connections.
>
> Therefore, this patch adds a tracepoint for __tcp_retransmit_skb()
> and exposes src/dst IP addresses and ports of the connection.
> This also makes it easier to integrate into perf.
>
> Note, I expose both IPv4 and IPv6 addresses at the same time:
> for a IPv4 socket, v4 mapped address is used as IPv6 addresses,
> for a IPv6 socket, LOOPBACK4_IPV6 is already filled by kernel.
> Also, add sk and skb pointers as they are useful for BPF.
>
> 1. https://github.com/brendangregg/perf-tools/blob/master/net/tcpretrans
>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thank you.
^ permalink raw reply
* Re: [Patch net-next] net_sched: fix a compile warning in act_ife
From: David Miller @ 2017-10-15 1:44 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, mrv
In-Reply-To: <20171013195813.25321-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 13 Oct 2017 12:58:13 -0700
> Apparently ife_meta_id2name() is only called when
> CONFIG_MODULES is defined.
>
> This fixes:
>
> net/sched/act_ife.c:251:20: warning: ‘ife_meta_id2name’ defined but not used [-Wunused-function]
> static const char *ife_meta_id2name(u32 metaid)
> ^~~~~~~~~~~~~~~~
>
> Fixes: d3f24ba895f0 ("net sched actions: fix module auto-loading")
> Cc: Roman Mashak <mrv@mojatatu.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next,0/3] Add init of send table and var renames
From: David Miller @ 2017-10-15 1:43 UTC (permalink / raw)
To: haiyangz, haiyangz; +Cc: netdev, kys, sthemmin, olaf, vkuznets, linux-kernel
In-Reply-To: <20171013192805.18183-1-haiyangz@exchange.microsoft.com>
From: Haiyang Zhang <haiyangz@exchange.microsoft.com>
Date: Fri, 13 Oct 2017 12:28:02 -0700
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> Add initialization of send indirection table. Otherwise it may contain
> old info of previous device with different number of channels.
>
> Also, did some variable renaming for easier reading.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net] l2tp: check ps->sock before running pppol2tp_session_ioctl()
From: David Miller @ 2017-10-15 1:39 UTC (permalink / raw)
To: g.nault; +Cc: netdev, jchapman, tparkin
In-Reply-To: <520e39809f7ca7d8b38282e3a6bf0bbf93219541.1507915312.git.g.nault@alphalink.fr>
From: Guillaume Nault <g.nault@alphalink.fr>
Date: Fri, 13 Oct 2017 19:22:35 +0200
> When pppol2tp_session_ioctl() is called by pppol2tp_tunnel_ioctl(),
> the session may be unconnected. That is, it was created by
> pppol2tp_session_create() and hasn't been connected with
> pppol2tp_connect(). In this case, ps->sock is NULL, so we need to check
> for this case in order to avoid dereferencing a NULL pointer.
>
> Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP")
> Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH][net-next] cxgb4: fix missing break in switch and indent return statements
From: David Miller @ 2017-10-15 1:38 UTC (permalink / raw)
To: colin.king; +Cc: ganeshgr, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20171013162900.16911-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 13 Oct 2017 17:29:00 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The break statement for the Macronix case is missing and will
> fall through to the Winbond case and re-assign the size setting.
> Fix this by adding the missing break statement. Also correctly
> indent the return statements.
>
> Detected by CoverityScan, CID#1458020 ("Missing break in switch")
>
> Fixes: 96ac18f14a5a ("cxgb4: Add support for new flash parts")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: pull-request: mac80211-next 2017-10-13
From: David Miller @ 2017-10-15 1:37 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20171013155332.4310-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 13 Oct 2017 17:53:31 +0200
> Sorry for the quick succession - there were a few issues with
> the last pull request that only got noticed now, so I'm fixing
> those here.
>
> Please pull and let me know if there's any problem.
No worries, pulled, thanks Johannes.
^ permalink raw reply
* Re: [PATCH net-next v2 0/8] cxgb4: add support to get hardware debug logs via ethtool
From: David Miller @ 2017-10-15 1:35 UTC (permalink / raw)
To: rahul.lakkireddy; +Cc: netdev, ganeshgr, nirranjan, indranil
In-Reply-To: <cover.1507899723.git.rahul.lakkireddy@chelsio.com>
From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date: Fri, 13 Oct 2017 18:48:12 +0530
> This series of patches add support to collect hardware debug logs
> via ethtool --get-dump facility.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH] nfp: Explicitly include linux/bug.h
From: David Miller @ 2017-10-15 1:31 UTC (permalink / raw)
To: broonie; +Cc: jakub.kicinski, simon.horman, oss-drivers, netdev
In-Reply-To: <20171013025035.4450-1-broonie@kernel.org>
From: Mark Brown <broonie@kernel.org>
Date: Fri, 13 Oct 2017 03:50:35 +0100
> Today's -next build encountered an error due to a missing definition of
> WARN_ON(), caused by some header reorganization removing an implicit
> inclusion of linux/bug.h. Fix this with an explicit inclusion.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
Applied, thanks Mark.
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] net: dsa: remove .set_addr
From: David Miller @ 2017-10-15 1:30 UTC (permalink / raw)
To: vivien.didelot
Cc: netdev, linux-kernel, kernel, f.fainelli, andrew, David.Laight
In-Reply-To: <20171013181809.14627-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Fri, 13 Oct 2017 14:18:04 -0400
> An Ethernet switch may support having a MAC address, which can be used
> as the switch's source address in transmitted full-duplex Pause frames.
>
> If a DSA switch supports the related .set_addr operation, the DSA core
> sets the master's MAC address on the switch.
>
> This won't make sense anymore in a multi-CPU ports system, because there
> won't be a unique master device assigned to a switch tree.
>
> Moreover this operation is confusing because it makes the user think
> that it could be used to program the switch with the MAC address of the
> CPU/management port such that MAC address learning can be disabled on
> said port, but in fact, that's not how it is currently used.
>
> To fix this, assign a random MAC address at setup time in the mv88e6060
> and mv88e6xxx drivers before removing .set_addr completely from DSA.
>
> Changes in v3:
> - include fix for mv88e6060 switch MAC address setter.
>
> Changes in v2:
> - remove .set_addr implementation from drivers and use a random MAC.
Series applied,thanks Vivien.
^ permalink raw reply
* Re: [PATCH] atm: fore200e: mark expected switch fall-throughs
From: David Miller @ 2017-10-15 1:25 UTC (permalink / raw)
To: garsilva; +Cc: 3chas3, linux-atm-general, netdev, linux-kernel
In-Reply-To: <20171012211132.GA6589@embeddedor.com>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Thu, 12 Oct 2017 16:11:32 -0500
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Applied to net-next
^ 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