Netdev List
 help / color / mirror / Atom feed
* Re: [patch net-next v2 0/9] net: sched: introduce chain templates support with offloading to mlxsw
From: Jiri Pirko @ 2018-06-28  6:25 UTC (permalink / raw)
  To: David Miller
  Cc: netdev, jhs, xiyou.wangcong, jakub.kicinski, simon.horman,
	john.hurley, dsahern, mlxsw
In-Reply-To: <20180628.134826.1129904828597717313.davem@davemloft.net>

Thu, Jun 28, 2018 at 06:48:26AM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Tue, 26 Jun 2018 09:59:51 +0200
>
>> For the TC clsact offload these days, some of HW drivers need
>> to hold a magic ball. The reason is, with the first inserted rule inside
>> HW they need to guess what fields will be used for the matching. If
>> later on this guess proves to be wrong and user adds a filter with a
>> different field to match, there's a problem. Mlxsw resolves it now with
>> couple of patterns. Those try to cover as many match fields as possible.
>> This aproach is far from optimal, both performance-wise and scale-wise.
>> Also, there is a combination of filters that in certain order won't
>> succeed.
>> 
>> Most of the time, when user inserts filters in chain, he knows right away
>> how the filters are going to look like - what type and option will they
>> have. For example, he knows that he will only insert filters of type
>> flower matching destination IP address. He can specify a template that
>> would cover all the filters in the chain.
>> 
>> This patchset is providing the possibility to user to provide such
>> template  to kernel and propagate it all the way down to device
>> drivers.
>
>This series doesn't apply cleanly to net-next, and also there seems to still
>be some discussion about how the iproute2 command line should look.

Will re-spin. Thanks.

>
>Thanks.

^ permalink raw reply

* Re: [patch net-next 0/9] net: sched: introduce chain templates support with offloading to mlxsw
From: Jiri Pirko @ 2018-06-28  6:18 UTC (permalink / raw)
  To: Cong Wang
  Cc: sridhar.samudrala, Jakub Kicinski,
	Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
	Simon Horman, john.hurley, David Ahern, mlxsw
In-Reply-To: <CAM_iQpUiod0iG=h8STfkKEPQoJUe==B0Q3oPj3kR5Wy7+5FBqA@mail.gmail.com>

Wed, Jun 27, 2018 at 07:04:32PM CEST, xiyou.wangcong@gmail.com wrote:
>On Wed, Jun 27, 2018 at 9:46 AM Samudrala, Sridhar
><sridhar.samudrala@intel.com> wrote:
>>
>> On 6/27/2018 12:50 AM, Jiri Pirko wrote:
>> > if you don't like "tc filter template add dev dummy0 ingress", how
>> > about:
>> > "tc template add dev dummy0 ingress ..."
>> > "tc template add dev dummy0 ingress chain 22 ..."
>> > that makes more sense I think.
>
>Better than 'tc filter template', but this doesn't reflect 'template'
>is a template of tc filter, it could be an action etc., since it is in the

It's a template of filter per chain. I don't understand how it could be
an action...


>same position with 'tc action/filter/qdisc'.
>
>
>>
>> Isn't it possible to avoid introducing another keyword 'template',
>>
>> Can't we just do
>>        tc chain add dev dummy0 ingress flower chain_index 0
>> to create a chain that takes any types of flower rules with index 0
>> and
>>       tc chain add dev dummy0 ingress flower chain_index 22
>>              dst_mac 00:00:00:00:00:00/00:00:00:00:FF:FF
>>       tc chain add dev dummy0 ingress flower chain_index 23
>>              dst_ip 192.168.0.0/16
>> to create 2 chains 22 and 23 that allow rules with specific fields.
>
>Sounds good too. Since filter chain can be shared by qdiscs,
>a 'tc chain' sub-command makes sense, and would probably make
>it easier to be shared.

We don't have such specific object. It is implicit. We create it
whenever someone users it. Either filter of chain. I don't like new "tc
chain" object in cmdline. It really isn't.

^ permalink raw reply

* Re: [patch net-next 0/9] net: sched: introduce chain templates support with offloading to mlxsw
From: Jiri Pirko @ 2018-06-28  6:15 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Linux Netdev List, David Miller, Jamal Hadi Salim, Cong Wang,
	Simon Horman, John Hurley, David Ahern, mlxsw
In-Reply-To: <20180627113624.5f8d74e9@cakuba.netronome.com>

Wed, Jun 27, 2018 at 08:36:24PM CEST, jakub.kicinski@netronome.com wrote:
>On Wed, 27 Jun 2018 09:50:17 +0200, Jiri Pirko wrote:
>> Tue, Jun 26, 2018 at 11:18:58PM CEST, jakub.kicinski@netronome.com wrote:
>> >On Tue, 26 Jun 2018 09:12:17 +0200, Jiri Pirko wrote:  
>> >> Tue, Jun 26, 2018 at 09:00:45AM CEST, jakub.kicinski@netronome.com wrote:  
>> >> >On Mon, Jun 25, 2018 at 11:43 PM, Jiri Pirko <jiri@resnulli.us> wrote:    
>> >> >> Tue, Jun 26, 2018 at 06:58:50AM CEST, jakub.kicinski@netronome.com wrote:    
>> >> >>>On Mon, 25 Jun 2018 23:01:39 +0200, Jiri Pirko wrote:    
>> >> >>>> From: Jiri Pirko <jiri@mellanox.com>
>> >> >>>>
>> >> >>>> For the TC clsact offload these days, some of HW drivers need
>> >> >>>> to hold a magic ball. The reason is, with the first inserted rule inside
>> >> >>>> HW they need to guess what fields will be used for the matching. If
>> >> >>>> later on this guess proves to be wrong and user adds a filter with a
>> >> >>>> different field to match, there's a problem. Mlxsw resolves it now with
>> >> >>>> couple of patterns. Those try to cover as many match fields as possible.
>> >> >>>> This aproach is far from optimal, both performance-wise and scale-wise.
>> >> >>>> Also, there is a combination of filters that in certain order won't
>> >> >>>> succeed.
>> >> >>>>
>> >> >>>> Most of the time, when user inserts filters in chain, he knows right away
>> >> >>>> how the filters are going to look like - what type and option will they
>> >> >>>> have. For example, he knows that he will only insert filters of type
>> >> >>>> flower matching destination IP address. He can specify a template that
>> >> >>>> would cover all the filters in the chain.    
>> >> >>>
>> >> >>>Perhaps it's lack of sleep, but this paragraph threw me a little off
>> >> >>>the track.  IIUC the goal of this set is to provide a way to inform the
>> >> >>>HW about expected matches before any rule is programmed into the HW.
>> >> >>>Not before any rule is added to a particular chain.  One can just use
>> >> >>>the first rule in the chain to make a guess about the chain, but thanks
>> >> >>>to this set user can configure *all* chains before any rules are added.    
>> >> >>
>> >> >> The template is per-chain. User can use template for chain x and
>> >> >> not-use it for chain y. Up to him.    
>> >> >
>> >> >Makes sense.
>> >> >
>> >> >I can't help but wonder if it'd be better to associate the
>> >> >constraints/rules with chains instead of creating a new "template"
>> >> >object.  It seems more natural to create a chain with specific
>> >> >constraints in place than add and delete template of which there can
>> >> >be at most one to a chain...  Perhaps that's more about the user space
>> >> >tc command line.  Anyway, not a strong objection, just a thought.    
>> >> 
>> >> Hmm. I don't think it is good idea. User should see the template in a
>> >> "show" command per chain. We would have to have 2 show commands, one to
>> >> list the template objects and one to list templates per chains. It makes
>> >> things more complicated for no good reason. I think that this simple
>> >> chain-lock is easier and serves the purpose.  
>> >
>> >Hm, I think the dump is fine, what I was thinking about was:
>> >
>> ># tc chain add dev dummy0 ingress chain_index 22 \
>> >     ^^^^^
>> >	template proto ip \
>> >	^^^^^^^^
>> >	flower dst_mac 00:00:00:00:00:00/00:00:00:00:FF:FF  
>> 
>> Okay, I got it. I see 2 issues.
>> 1) user might expect to add a chain without the template. But that does
>>    not make sense really. Chains are created/deleted implicitly
>>    according to refcount.
>> 2) there is not chain object like this available to user. Adding it just
>>    for template looks odd. Also, the "filter" and "template" are very
>>    much alike. They both are added to a chain, they both implicitly
>>    create chain if it does not exist, etc.
>
>Yeah, that part makes is tricky :/
>
>> if you don't like "tc filter template add dev dummy0 ingress", how
>> about:
>> "tc template add dev dummy0 ingress ..."
>> "tc template add dev dummy0 ingress chain 22 ..."
>> that makes more sense I think.
>
>Mmm..  how about:
>
> tc chaintemplate add dev dummy0 ingress...

This looks fine to me.

>
>or
>
> tc restrictedchain add dev dummy0 ingress chain_index XX template ...

^ permalink raw reply

* Re: [PATCH] bpfilter: fix user mode helper cross compilation
From: Andrew Morton @ 2018-06-28  6:17 UTC (permalink / raw)
  To: Matteo Croce; +Cc: netdev
In-Reply-To: <20180620140434.18139-1-mcroce@redhat.com>

On Wed, 20 Jun 2018 16:04:34 +0200 Matteo Croce <mcroce@redhat.com> wrote:

> Use $(OBJDUMP) instead of literal 'objdump' to avoid
> using host toolchain when cross compiling.
> 

I'm still having issues here, with ld.

x86_64 machine, ARCH=i386:

y:/usr/src/25> make V=1 M=net/bpfilter
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (       \
echo >&2;                                                       \
echo >&2 "  ERROR: Kernel configuration is invalid.";           \
echo >&2 "         include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it.";      \
echo >&2 ;                                                      \
/bin/false)
mkdir -p net/bpfilter/.tmp_versions ; rm -f net/bpfilter/.tmp_versions/*
make -f ./scripts/Makefile.build obj=net/bpfilter
(cat /dev/null;   echo kernel/net/bpfilter/bpfilter.ko;) > net/bpfilter/modules.order
  ld -m elf_i386   -r -o net/bpfilter/bpfilter.o net/bpfilter/bpfilter_kern.o net/bpfilter/bpfilter_umh.o ; scripts/mod/modpost net/bpfilter/bpfilter.o
ld: i386:x86-64 architecture of input file `net/bpfilter/bpfilter_umh.o' is incompatible with i386 output
scripts/Makefile.build:530: recipe for target 'net/bpfilter/bpfilter.o' failed
make[1]: *** [net/bpfilter/bpfilter.o] Error 1
Makefile:1518: recipe for target '_module_net/bpfilter' failed
make: *** [_module_net/bpfilter] Error 2

y:/usr/src/25> ld --version
GNU ld (GNU Binutils for Ubuntu) 2.29.1

^ permalink raw reply

* Re: [PATCH 0/3] xdp: don't mix XDP_TX and XDP_REDIRECT flush ops
From: David Miller @ 2018-06-28  5:29 UTC (permalink / raw)
  To: brouer
  Cc: netdev, john.fastabend, jasowang, borkmann, bjorn.topel,
	alexei.starovoitov
In-Reply-To: <153002741940.15389.10466368482771753300.stgit@firesoul>

From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Tue, 26 Jun 2018 17:39:43 +0200

> Fix driver logic that are combining XDP_TX flush and XDP_REDIRECT map
> flushing.  These are two different XDP xmit modes, and it is clearly
> wrong to invoke both types of flush operations when only one of the
> XDP xmit modes is used.

Series applied and queued up for -stable, thanks Jesper.

^ permalink raw reply

* Re: [PATCH net-next 1/1] tc-tests: add an extreme-case csum action test
From: David Miller @ 2018-06-28  5:24 UTC (permalink / raw)
  To: kleib; +Cc: netdev, jhs, xiyou.wangcong, jiri, lucasb
In-Reply-To: <1530022588-27685-1-git-send-email-kleib@mojatatu.com>

From: Keara Leibovitz <kleib@mojatatu.com>
Date: Tue, 26 Jun 2018 10:16:28 -0400

> Added an extreme-case test for all 7 csum action headers.
> 
> Signed-off-by: Keara Leibovitz <kleib@mojatatu.com>

Applied, thank you.

^ permalink raw reply

* Re: [PATCH net-next v2 0/2] net: mscc: ocelot: add more features
From: David Miller @ 2018-06-28  5:19 UTC (permalink / raw)
  To: alexandre.belloni
  Cc: Allan.Nielsen, razvan.stefanescu, po.liu, thomas.petazzoni,
	andrew, f.fainelli, netdev, linux-kernel
In-Reply-To: <20180626122849.13174-1-alexandre.belloni@bootlin.com>

From: Alexandre Belloni <alexandre.belloni@bootlin.com>
Date: Tue, 26 Jun 2018 14:28:47 +0200

> Hi,
> 
> This series adds link aggregation and VLAN filtering hardware offload
> support to the ocelot driver.
> 
> PTP support will be sent later.
> 
> changes in v2:
>  - rebased on v4.18-rc1
>  - check for aggregation type and only offload it when type is hash (balance-xor
>    or 802.3ad)

Series applied, thank you.

^ permalink raw reply

* Re: [PATCH net-next] cxgb4: Add new T5 PCI device id 0x50ae
From: David Miller @ 2018-06-28  4:51 UTC (permalink / raw)
  To: ganeshgr; +Cc: netdev, nirranjan, indranil
In-Reply-To: <1530004873-19098-1-git-send-email-ganeshgr@chelsio.com>

From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Tue, 26 Jun 2018 14:51:13 +0530

> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] cxgb4: Add flag tc_flower_initialized
From: David Miller @ 2018-06-28  4:51 UTC (permalink / raw)
  To: ganeshgr; +Cc: netdev, nirranjan, indranil, leedom
In-Reply-To: <1530004728-18913-1-git-send-email-ganeshgr@chelsio.com>

From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Tue, 26 Jun 2018 14:48:48 +0530

> From: Casey Leedom <leedom@chelsio.com>
> 
> Add flag tc_flower_initialized to indicate the
> completion if tc flower initialization.
> 
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>

Applied.

^ permalink raw reply

* Re: [PATCH net] net: macb: initialize bp->queues[0].bp for at91rm9200
From: David Miller @ 2018-06-28  4:50 UTC (permalink / raw)
  To: alexandre.belloni; +Cc: rafalo, nicolas.ferre, netdev, linux-kernel
In-Reply-To: <20180626084401.16780-1-alexandre.belloni@bootlin.com>

From: Alexandre Belloni <alexandre.belloni@bootlin.com>
Date: Tue, 26 Jun 2018 10:44:01 +0200

> The macb driver currently crashes on at91rm9200 with the following trace:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000014
> [...]
> [<c031da44>] (macb_rx_desc) from [<c031f2bc>] (at91ether_open+0x2e8/0x3f8)
> [<c031f2bc>] (at91ether_open) from [<c041e8d8>] (__dev_open+0x120/0x13c)
> [<c041e8d8>] (__dev_open) from [<c041ec08>] (__dev_change_flags+0x17c/0x1a8)
> [<c041ec08>] (__dev_change_flags) from [<c041ec4c>] (dev_change_flags+0x18/0x4c)
> [<c041ec4c>] (dev_change_flags) from [<c07a5f4c>] (ip_auto_config+0x220/0x10b0)
> [<c07a5f4c>] (ip_auto_config) from [<c000a4fc>] (do_one_initcall+0x78/0x18c)
> [<c000a4fc>] (do_one_initcall) from [<c0783e50>] (kernel_init_freeable+0x184/0x1c4)
> [<c0783e50>] (kernel_init_freeable) from [<c0574d70>] (kernel_init+0x8/0xe8)
> [<c0574d70>] (kernel_init) from [<c00090e0>] (ret_from_fork+0x14/0x34)
> 
> Solve that by initializing bp->queues[0].bp in at91ether_init (as is done
> in macb_init).
> 
> Fixes: ae1f2a56d273 ("net: macb: Added support for many RX queues")
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

Applied and queued up for -stable.

^ permalink raw reply

* Re: [patch net-next v2 0/9] net: sched: introduce chain templates support with offloading to mlxsw
From: David Miller @ 2018-06-28  4:48 UTC (permalink / raw)
  To: jiri
  Cc: netdev, jhs, xiyou.wangcong, jakub.kicinski, simon.horman,
	john.hurley, dsahern, mlxsw
In-Reply-To: <20180626080000.12964-1-jiri@resnulli.us>

From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 26 Jun 2018 09:59:51 +0200

> For the TC clsact offload these days, some of HW drivers need
> to hold a magic ball. The reason is, with the first inserted rule inside
> HW they need to guess what fields will be used for the matching. If
> later on this guess proves to be wrong and user adds a filter with a
> different field to match, there's a problem. Mlxsw resolves it now with
> couple of patterns. Those try to cover as many match fields as possible.
> This aproach is far from optimal, both performance-wise and scale-wise.
> Also, there is a combination of filters that in certain order won't
> succeed.
> 
> Most of the time, when user inserts filters in chain, he knows right away
> how the filters are going to look like - what type and option will they
> have. For example, he knows that he will only insert filters of type
> flower matching destination IP address. He can specify a template that
> would cover all the filters in the chain.
> 
> This patchset is providing the possibility to user to provide such
> template  to kernel and propagate it all the way down to device
> drivers.

This series doesn't apply cleanly to net-next, and also there seems to still
be some discussion about how the iproute2 command line should look.

Thanks.

^ permalink raw reply

* Re: [PATCH net-next v2] net: vhost: improve performance when enable busyloop
From: Jason Wang @ 2018-06-28  4:40 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: xiangxia.m.yue, virtualization, netdev, Tonghao Zhang
In-Reply-To: <20180627185543-mutt-send-email-mst@kernel.org>



On 2018年06月27日 23:58, Michael S. Tsirkin wrote:
> On Wed, Jun 27, 2018 at 10:24:43PM +0800, Jason Wang wrote:
>>
>> On 2018年06月26日 13:17, xiangxia.m.yue@gmail.com wrote:
>>> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>>
>>> This patch improves the guest receive performance from
>>> host. On the handle_tx side, we poll the sock receive
>>> queue at the same time. handle_rx do that in the same way.
>>>
>>> For avoiding deadlock, change the code to lock the vq one
>>> by one and use the VHOST_NET_VQ_XX as a subclass for
>>> mutex_lock_nested. With the patch, qemu can set differently
>>> the busyloop_timeout for rx or tx queue.
>>>
>>> We set the poll-us=100us and use the iperf3 to test
>>> its throughput. The iperf3 command is shown as below.
>>>
>>> on the guest:
>>> iperf3  -s -D
>>>
>>> on the host:
>>> iperf3  -c 192.168.1.100 -i 1 -P 10 -t 10 -M 1400
>>>
>>> * With the patch:     23.1 Gbits/sec
>>> * Without the patch:  12.7 Gbits/sec
>>>
>>> Signed-off-by: Tonghao Zhang <zhangtonghao@didichuxing.com>
>> Thanks a lot for the patch. Looks good generally, but please split this big
>> patch into separate ones like:
>>
>> patch 1: lock vqs one by one
>> patch 2: replace magic number of lock annotation
>> patch 3: factor out generic busy polling logic to vhost_net_busy_poll()
>> patch 4: add rx busy polling in tx path.
>>
>> And please cc Michael in v3.
>>
>> Thanks
> Pls include host CPU utilization numbers. You can get them e.g. using
> vmstat. I suspect we also want the polling controllable e.g. through
> an ioctl.
>

I believe we had an ioctl for setting timeout? Or you want another kind 
of controlling.

Thanks

^ permalink raw reply

* Re: [RESEND PATCH] bpfilter: check compiler capability in Kconfig
From: David Miller @ 2018-06-28  4:37 UTC (permalink / raw)
  To: yamada.masahiro
  Cc: netdev, alexei.starovoitov, mcroce, arnd, linux-kbuild, ast,
	linux-kernel, michal.lkml, daniel
In-Reply-To: <1529985336-27522-1-git-send-email-yamada.masahiro@socionext.com>

From: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Tue, 26 Jun 2018 12:55:35 +0900

> With the brand-new syntax extension of Kconfig, we can directly
> check the compiler capability in the configuration phase.
> 
> If the cc-can-link.sh fails, the BPFILTER_UMH is automatically
> hidden by the dependency.
> 
> I also deleted 'default n', which is no-op.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Applied, thank you.

^ permalink raw reply

* Re: [PATCH] hinic: reset irq affinity before freeing irq
From: David Miller @ 2018-06-28  4:35 UTC (permalink / raw)
  To: weiyongjun1; +Cc: aviad.krawczyk, netdev
In-Reply-To: <1530092857-73580-1-git-send-email-weiyongjun1@huawei.com>

From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Wed, 27 Jun 2018 17:47:37 +0800

> Following warning is seen when rmmod hinic. This is because affinity
> value is not reset before calling free_irq(). This patch fixes it.
> 
> [   55.181232] WARNING: CPU: 38 PID: 19589 at kernel/irq/manage.c:1608
> __free_irq+0x2aa/0x2c0
> 
> Fixes: 352f58b0d9f2 ("net-next/hinic: Set Rxq irq to specific cpu for NUMA")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>

Applied and queued up for -stable.

^ permalink raw reply

* Re: [PATCH 0/6] Netfilter fixes for net
From: David Miller @ 2018-06-28  4:33 UTC (permalink / raw)
  To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20180627152223.3633-1-pablo@netfilter.org>

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 27 Jun 2018 17:22:17 +0200

> The following patchset contains Netfilter fixes for your net tree:
> 
> 1) Missing netlink attribute validation in nf_queue, uncovered by KASAN,
>    from Eric Dumazet.
> 
> 2) Use pointer to sysctl table, save us 192 bytes of memory per netns.
>    Also from Eric.
> 
> 3) Possible use-after-free when removing conntrack helper modules due
>    to missing synchronize RCU call. From Taehee Yoo.
> 
> 4) Fix corner case in systcl writes to nf_log that lead to appending
>    data to uninitialized buffer, from Jann Horn.
> 
> 5) Jann Horn says we may indefinitely block other users of nf_log_mutex
>    if a userspace access in proc_dostring() blocked e.g. due to a
>    userfaultfd.
> 
> 6) Fix garbage collection race for unconfirmed conntrack entries,
>    from Florian Westphal.
> 
> You can pull these changes from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git

Pulled, thank you.

^ permalink raw reply

* [PATCH v2 net-next] tcp: add new SNMP counter for drops when try to queue in rcv queue
From: Yafang Shao @ 2018-06-28  4:22 UTC (permalink / raw)
  To: edumazet; +Cc: davem, netdev, linux-kernel, Yafang Shao

When sk_rmem_alloc is larger than the receive buffer and we can't
schedule more memory for it, the skb will be dropped.

In above situation, if this skb is put into the ofo queue,
LINUX_MIB_TCPOFODROP is incremented to track it.

While if this skb is put into the receive queue, there's no record.
So a new SNMP counter is introduced to track this behavior.

LINUX_MIB_TCPRCVQDROP:  Number of packets meant to be queued in rcv queue
			but dropped because socket rcvbuf limit hit.

Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
 include/uapi/linux/snmp.h | 1 +
 net/ipv4/proc.c           | 1 +
 net/ipv4/tcp_input.c      | 8 ++++++--
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
index 97517f3..e5ebc83 100644
--- a/include/uapi/linux/snmp.h
+++ b/include/uapi/linux/snmp.h
@@ -280,6 +280,7 @@ enum
 	LINUX_MIB_TCPDELIVEREDCE,		/* TCPDeliveredCE */
 	LINUX_MIB_TCPACKCOMPRESSED,		/* TCPAckCompressed */
 	LINUX_MIB_TCPZEROWINDOWDROP,		/* TCPZeroWindowDrop */
+	LINUX_MIB_TCPRCVQDROP,			/* TCPRcvQDrop */
 	__LINUX_MIB_MAX
 };
 
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 225ef34..b46e4cf 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -288,6 +288,7 @@ static int sockstat_seq_show(struct seq_file *seq, void *v)
 	SNMP_MIB_ITEM("TCPDeliveredCE", LINUX_MIB_TCPDELIVEREDCE),
 	SNMP_MIB_ITEM("TCPAckCompressed", LINUX_MIB_TCPACKCOMPRESSED),
 	SNMP_MIB_ITEM("TCPZeroWindowDrop", LINUX_MIB_TCPZEROWINDOWDROP),
+	SNMP_MIB_ITEM("TCPRcvQDrop", LINUX_MIB_TCPRCVQDROP),
 	SNMP_MIB_SENTINEL
 };
 
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 9c5b341..eecd359 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4611,8 +4611,10 @@ int tcp_send_rcvq(struct sock *sk, struct msghdr *msg, size_t size)
 	skb->data_len = data_len;
 	skb->len = size;
 
-	if (tcp_try_rmem_schedule(sk, skb, skb->truesize))
+	if (tcp_try_rmem_schedule(sk, skb, skb->truesize)) {
+		NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPRCVQDROP);
 		goto err_free;
+	}
 
 	err = skb_copy_datagram_from_iter(skb, 0, &msg->msg_iter, size);
 	if (err)
@@ -4677,8 +4679,10 @@ static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
 queue_and_out:
 		if (skb_queue_len(&sk->sk_receive_queue) == 0)
 			sk_forced_mem_schedule(sk, skb->truesize);
-		else if (tcp_try_rmem_schedule(sk, skb, skb->truesize))
+		else if (tcp_try_rmem_schedule(sk, skb, skb->truesize)) {
+			NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPRCVQDROP);
 			goto drop;
+		}
 
 		eaten = tcp_queue_rcv(sk, skb, 0, &fragstolen);
 		tcp_rcv_nxt_update(tp, TCP_SKB_CB(skb)->end_seq);
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH net-next 11/11] net: hns3: use lower_32_bits and upper_32_bits
From: Peng Li @ 2018-06-28  4:12 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
	lipeng321
In-Reply-To: <1530159149-122284-1-git-send-email-lipeng321@huawei.com>

From: Huazhong Tan <tanhuazhong@huawei.com>

MACRO lower_32_bits and upper_32_bits can help to get bits 0-31
and bits 32-63 of a number, so just use it.

Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index 7049d0b..383ecf0 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -123,9 +123,9 @@ static void hclge_cmd_config_regs(struct hclge_cmq_ring *ring)
 
 	if (ring->flag == HCLGE_TYPE_CSQ) {
 		hclge_write_dev(hw, HCLGE_NIC_CSQ_BASEADDR_L_REG,
-				(u32)dma);
+				lower_32_bits(dma));
 		hclge_write_dev(hw, HCLGE_NIC_CSQ_BASEADDR_H_REG,
-				(u32)((dma >> 31) >> 1));
+				upper_32_bits(dma));
 		hclge_write_dev(hw, HCLGE_NIC_CSQ_DEPTH_REG,
 				(ring->desc_num >> HCLGE_NIC_CMQ_DESC_NUM_S) |
 				HCLGE_NIC_CMQ_ENABLE);
@@ -133,9 +133,9 @@ static void hclge_cmd_config_regs(struct hclge_cmq_ring *ring)
 		hclge_write_dev(hw, HCLGE_NIC_CSQ_HEAD_REG, 0);
 	} else {
 		hclge_write_dev(hw, HCLGE_NIC_CRQ_BASEADDR_L_REG,
-				(u32)dma);
+				lower_32_bits(dma));
 		hclge_write_dev(hw, HCLGE_NIC_CRQ_BASEADDR_H_REG,
-				(u32)((dma >> 31) >> 1));
+				upper_32_bits(dma));
 		hclge_write_dev(hw, HCLGE_NIC_CRQ_DEPTH_REG,
 				(ring->desc_num >> HCLGE_NIC_CMQ_DESC_NUM_S) |
 				HCLGE_NIC_CMQ_ENABLE);
-- 
2.9.3

^ permalink raw reply related

* [PATCH net-next 09/11] net: hns3: remove the Redundant put_vector in hns3_client_uninit
From: Peng Li @ 2018-06-28  4:12 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
	lipeng321
In-Reply-To: <1530159149-122284-1-git-send-email-lipeng321@huawei.com>

The interface h->ae_algo->ops->put_vector is called in both
hns3_nic_dealloc_vector_data and hns3_nic_uninit_vector_data in
hns3_client_uninit, this will cause vector freed twice.
This patch remove the Redundant put_vector to make vector freed
only once.

Signed-off-by: Peng Li <lipeng321@huawei.com>
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 1a68952..beca364 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2745,10 +2745,6 @@ static int hns3_nic_uninit_vector_data(struct hns3_nic_priv *priv)
 		if (ret)
 			return ret;
 
-		ret = h->ae_algo->ops->put_vector(h, tqp_vector->vector_irq);
-		if (ret)
-			return ret;
-
 		hns3_free_vector_ring_chain(tqp_vector, &vector_ring_chain);
 
 		if (priv->tqp_vector[i].irq_init_flag == HNS3_VECTOR_INITED) {
-- 
2.9.3

^ permalink raw reply related

* [PATCH net-next 08/11] net: hns3: print the ret value in error information
From: Peng Li @ 2018-06-28  4:12 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
	lipeng321
In-Reply-To: <1530159149-122284-1-git-send-email-lipeng321@huawei.com>

Print the ret value in error information can help find the reason.

Signed-off-by: Peng Li <lipeng321@huawei.com>
---
 drivers/net/ethernet/hisilicon/hns3/hnae3.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 3e5c83f..1a02620 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -94,7 +94,7 @@ static int hnae3_match_n_instantiate(struct hnae3_client *client,
 		ret = ae_dev->ops->init_client_instance(client, ae_dev);
 		if (ret) {
 			dev_err(&ae_dev->pdev->dev,
-				"fail to instantiate client\n");
+				"fail to instantiate client, ret = %d\n", ret);
 			return ret;
 		}
 
@@ -134,7 +134,8 @@ int hnae3_register_client(struct hnae3_client *client)
 		ret = hnae3_match_n_instantiate(client, ae_dev, true);
 		if (ret)
 			dev_err(&ae_dev->pdev->dev,
-				"match and instantiation failed for port\n");
+				"match and instantiation failed for port, ret = %d\n",
+				ret);
 	}
 
 exit:
@@ -184,7 +185,8 @@ void hnae3_register_ae_algo(struct hnae3_ae_algo *ae_algo)
 		ae_dev->ops = ae_algo->ops;
 		ret = ae_algo->ops->init_ae_dev(ae_dev);
 		if (ret) {
-			dev_err(&ae_dev->pdev->dev, "init ae_dev error.\n");
+			dev_err(&ae_dev->pdev->dev,
+				"init ae_dev error, ret = %d\n", ret);
 			continue;
 		}
 
@@ -197,7 +199,8 @@ void hnae3_register_ae_algo(struct hnae3_ae_algo *ae_algo)
 			ret = hnae3_match_n_instantiate(client, ae_dev, true);
 			if (ret)
 				dev_err(&ae_dev->pdev->dev,
-					"match and instantiation failed\n");
+					"match and instantiation failed, ret = %d\n",
+					ret);
 		}
 	}
 
@@ -270,7 +273,8 @@ void hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev)
 		/* ae_dev init should set flag */
 		ret = ae_dev->ops->init_ae_dev(ae_dev);
 		if (ret) {
-			dev_err(&ae_dev->pdev->dev, "init ae_dev error\n");
+			dev_err(&ae_dev->pdev->dev,
+				"init ae_dev error, ret = %d\n", ret);
 			goto out_err;
 		}
 
@@ -285,7 +289,8 @@ void hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev)
 		ret = hnae3_match_n_instantiate(client, ae_dev, true);
 		if (ret)
 			dev_err(&ae_dev->pdev->dev,
-				"match and instantiation failed\n");
+				"match and instantiation failed, ret = %d\n",
+				ret);
 	}
 
 out_err:
-- 
2.9.3

^ permalink raw reply related

* [PATCH net-next 07/11] net: hns3: extraction an interface for state init|uninit
From: Peng Li @ 2018-06-28  4:12 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
	lipeng321
In-Reply-To: <1530159149-122284-1-git-send-email-lipeng321@huawei.com>

Extraction an interface for state init|uninit to make the code
easier to read.

Signed-off-by: Peng Li <lipeng321@huawei.com>
---
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c    | 42 +++++++++++++---------
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 2b903f4..805c780 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -5568,6 +5568,30 @@ static void hclge_pci_uninit(struct hclge_dev *hdev)
 	pci_disable_device(pdev);
 }
 
+static void hclge_state_init(struct hclge_dev *hdev)
+{
+	set_bit(HCLGE_STATE_SERVICE_INITED, &hdev->state);
+	set_bit(HCLGE_STATE_DOWN, &hdev->state);
+	clear_bit(HCLGE_STATE_RST_SERVICE_SCHED, &hdev->state);
+	clear_bit(HCLGE_STATE_RST_HANDLING, &hdev->state);
+	clear_bit(HCLGE_STATE_MBX_SERVICE_SCHED, &hdev->state);
+	clear_bit(HCLGE_STATE_MBX_HANDLING, &hdev->state);
+}
+
+static void hclge_state_uninit(struct hclge_dev *hdev)
+{
+	set_bit(HCLGE_STATE_DOWN, &hdev->state);
+
+	if (hdev->service_timer.function)
+		del_timer_sync(&hdev->service_timer);
+	if (hdev->service_task.func)
+		cancel_work_sync(&hdev->service_task);
+	if (hdev->rst_service_task.func)
+		cancel_work_sync(&hdev->rst_service_task);
+	if (hdev->mbx_service_task.func)
+		cancel_work_sync(&hdev->mbx_service_task);
+}
+
 static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
 {
 	struct pci_dev *pdev = ae_dev->pdev;
@@ -5708,12 +5732,7 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
 	/* Enable MISC vector(vector0) */
 	hclge_enable_vector(&hdev->misc_vector, true);
 
-	set_bit(HCLGE_STATE_SERVICE_INITED, &hdev->state);
-	set_bit(HCLGE_STATE_DOWN, &hdev->state);
-	clear_bit(HCLGE_STATE_RST_SERVICE_SCHED, &hdev->state);
-	clear_bit(HCLGE_STATE_RST_HANDLING, &hdev->state);
-	clear_bit(HCLGE_STATE_MBX_SERVICE_SCHED, &hdev->state);
-	clear_bit(HCLGE_STATE_MBX_HANDLING, &hdev->state);
+	hclge_state_init(hdev);
 
 	pr_info("%s driver initialization finished.\n", HCLGE_DRIVER_NAME);
 	return 0;
@@ -5818,16 +5837,7 @@ static void hclge_uninit_ae_dev(struct hnae3_ae_dev *ae_dev)
 	struct hclge_dev *hdev = ae_dev->priv;
 	struct hclge_mac *mac = &hdev->hw.mac;
 
-	set_bit(HCLGE_STATE_DOWN, &hdev->state);
-
-	if (hdev->service_timer.function)
-		del_timer_sync(&hdev->service_timer);
-	if (hdev->service_task.func)
-		cancel_work_sync(&hdev->service_task);
-	if (hdev->rst_service_task.func)
-		cancel_work_sync(&hdev->rst_service_task);
-	if (hdev->mbx_service_task.func)
-		cancel_work_sync(&hdev->mbx_service_task);
+	hclge_state_uninit(hdev);
 
 	if (mac->phydev)
 		mdiobus_unregister(mac->mdio_bus);
-- 
2.9.3

^ permalink raw reply related

* [PATCH net-next 06/11] net: hns3: remove unused head file in hnae3.c
From: Peng Li @ 2018-06-28  4:12 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
	lipeng321
In-Reply-To: <1530159149-122284-1-git-send-email-lipeng321@huawei.com>

linux/slab.h is not used in hnae3.h, this patch removes it.

Signed-off-by: Peng Li <lipeng321@huawei.com>
---
 drivers/net/ethernet/hisilicon/hns3/hnae3.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 9d79dad..3e5c83f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -8,7 +8,6 @@
  */
 
 #include <linux/list.h>
-#include <linux/slab.h>
 #include <linux/spinlock.h>
 
 #include "hnae3.h"
-- 
2.9.3

^ permalink raw reply related

* [PATCH net-next 05/11] net: hns3: add unlikely for error check
From: Peng Li @ 2018-06-28  4:12 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
	lipeng321
In-Reply-To: <1530159149-122284-1-git-send-email-lipeng321@huawei.com>

The first bd of a packet is invalid and invalid ring head for tx
IRQ is not offen, they may occur when there is error,
Add unlikely for error check branch is better for performance.

Signed-off-by: Peng Li <lipeng321@huawei.com>
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 99bb6a8..1a68952 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1917,7 +1917,7 @@ bool hns3_clean_tx_ring(struct hns3_enet_ring *ring, int budget)
 	if (is_ring_empty(ring) || head == ring->next_to_clean)
 		return true; /* no data to poll */
 
-	if (!is_valid_clean_head(ring, head)) {
+	if (unlikely(!is_valid_clean_head(ring, head))) {
 		netdev_err(netdev, "wrong head (%d, %d-%d)\n", head,
 			   ring->next_to_use, ring->next_to_clean);
 
@@ -2174,7 +2174,7 @@ static int hns3_handle_rx_bd(struct hns3_enet_ring *ring,
 	bd_base_info = le32_to_cpu(desc->rx.bd_base_info);
 
 	/* Check valid BD */
-	if (!hnae_get_bit(bd_base_info, HNS3_RXD_VLD_B))
+	if (unlikely(!hnae_get_bit(bd_base_info, HNS3_RXD_VLD_B)))
 		return -EFAULT;
 
 	va = (unsigned char *)desc_cb->buf + desc_cb->page_offset;
-- 
2.9.3

^ permalink raw reply related

* [PATCH net-next 04/11] net: hns3: add l4_type check for both ipv4 and ipv6
From: Peng Li @ 2018-06-28  4:12 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
	lipeng321
In-Reply-To: <1530159149-122284-1-git-send-email-lipeng321@huawei.com>

HW supports UDP, TCP and SCTP packets checksum for both ipv4 and
ipv6,  but do not support other type packets checksum for ipv4 or
ipv6.

Signed-off-by: Peng Li <lipeng321@huawei.com>
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 25a73bb..99bb6a8 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2103,11 +2103,11 @@ static void hns3_rx_checksum(struct hns3_enet_ring *ring, struct sk_buff *skb,
 		skb->csum_level = 1;
 	case HNS3_OL4_TYPE_NO_TUN:
 		/* Can checksum ipv4 or ipv6 + UDP/TCP/SCTP packets */
-		if (l3_type == HNS3_L3_TYPE_IPV4 ||
-		    (l3_type == HNS3_L3_TYPE_IPV6 &&
-		     (l4_type == HNS3_L4_TYPE_UDP ||
-		      l4_type == HNS3_L4_TYPE_TCP ||
-		      l4_type == HNS3_L4_TYPE_SCTP)))
+		if ((l3_type == HNS3_L3_TYPE_IPV4 ||
+		     l3_type == HNS3_L3_TYPE_IPV6) &&
+		    (l4_type == HNS3_L4_TYPE_UDP ||
+		     l4_type == HNS3_L4_TYPE_TCP ||
+		     l4_type == HNS3_L4_TYPE_SCTP))
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 		break;
 	}
-- 
2.9.3

^ permalink raw reply related

* [PATCH net-next 03/11] net: hns3: add vector status check before free vector
From: Peng Li @ 2018-06-28  4:12 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
	lipeng321
In-Reply-To: <1530159149-122284-1-git-send-email-lipeng321@huawei.com>

If the hdev->vector_status[vector_id] is already HCLGE_INVALID_VPORT,
should log the error and return.

Signed-off-by: Peng Li <lipeng321@huawei.com>
---
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c   | 6 ++++++
 drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 6 ++++++
 2 files changed, 12 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index d318d35..2b903f4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2614,6 +2614,12 @@ static irqreturn_t hclge_misc_irq_handle(int irq, void *data)
 
 static void hclge_free_vector(struct hclge_dev *hdev, int vector_id)
 {
+	if (hdev->vector_status[vector_id] == HCLGE_INVALID_VPORT) {
+		dev_warn(&hdev->pdev->dev,
+			 "vector(vector_id %d) has been freed.\n", vector_id);
+		return;
+	}
+
 	hdev->vector_status[vector_id] = HCLGE_INVALID_VPORT;
 	hdev->num_msi_left += 1;
 	hdev->num_msi_used -= 1;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 3a8d7e0..1eb61c1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -330,6 +330,12 @@ static int hclgevf_set_handle_info(struct hclgevf_dev *hdev)
 
 static void hclgevf_free_vector(struct hclgevf_dev *hdev, int vector_id)
 {
+	if (hdev->vector_status[vector_id] == HCLGEVF_INVALID_VPORT) {
+		dev_warn(&hdev->pdev->dev,
+			 "vector(vector_id %d) has been freed.\n", vector_id);
+		return;
+	}
+
 	hdev->vector_status[vector_id] = HCLGEVF_INVALID_VPORT;
 	hdev->num_msi_left += 1;
 	hdev->num_msi_used -= 1;
-- 
2.9.3

^ permalink raw reply related

* [PATCH net-next 02/11] net: hns3: rename the interface for init_client_instance and uninit_client_instance
From: Peng Li @ 2018-06-28  4:12 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
	lipeng321
In-Reply-To: <1530159149-122284-1-git-send-email-lipeng321@huawei.com>

The interface init_client_instance and uninit_client_instance
do not register anything, only initialize the client instance.
This patch rename the related interface to make the function
name to indicate the purpose.

Signed-off-by: Peng Li <lipeng321@huawei.com>
---
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c  | 31 +++++++---------------
 1 file changed, 9 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index b3d8237..3a8d7e0 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -1586,9 +1586,10 @@ static void hclgevf_misc_irq_uninit(struct hclgevf_dev *hdev)
 	hclgevf_free_vector(hdev, 0);
 }
 
-static int hclgevf_init_instance(struct hclgevf_dev *hdev,
-				 struct hnae3_client *client)
+static int hclgevf_init_client_instance(struct hnae3_client *client,
+					struct hnae3_ae_dev *ae_dev)
 {
+	struct hclgevf_dev *hdev = ae_dev->priv;
 	int ret;
 
 	switch (client->type) {
@@ -1639,9 +1640,11 @@ static int hclgevf_init_instance(struct hclgevf_dev *hdev,
 	return 0;
 }
 
-static void hclgevf_uninit_instance(struct hclgevf_dev *hdev,
-				    struct hnae3_client *client)
+static void hclgevf_uninit_client_instance(struct hnae3_client *client,
+					   struct hnae3_ae_dev *ae_dev)
 {
+	struct hclgevf_dev *hdev = ae_dev->priv;
+
 	/* un-init roce, if it exists */
 	if (hdev->roce_client)
 		hdev->roce_client->ops->uninit_instance(&hdev->roce, 0);
@@ -1652,22 +1655,6 @@ static void hclgevf_uninit_instance(struct hclgevf_dev *hdev,
 		client->ops->uninit_instance(&hdev->nic, 0);
 }
 
-static int hclgevf_register_client(struct hnae3_client *client,
-				   struct hnae3_ae_dev *ae_dev)
-{
-	struct hclgevf_dev *hdev = ae_dev->priv;
-
-	return hclgevf_init_instance(hdev, client);
-}
-
-static void hclgevf_unregister_client(struct hnae3_client *client,
-				      struct hnae3_ae_dev *ae_dev)
-{
-	struct hclgevf_dev *hdev = ae_dev->priv;
-
-	hclgevf_uninit_instance(hdev, client);
-}
-
 static int hclgevf_pci_init(struct hclgevf_dev *hdev)
 {
 	struct pci_dev *pdev = hdev->pdev;
@@ -1928,8 +1915,8 @@ void hclgevf_update_speed_duplex(struct hclgevf_dev *hdev, u32 speed,
 static const struct hnae3_ae_ops hclgevf_ops = {
 	.init_ae_dev = hclgevf_init_ae_dev,
 	.uninit_ae_dev = hclgevf_uninit_ae_dev,
-	.init_client_instance = hclgevf_register_client,
-	.uninit_client_instance = hclgevf_unregister_client,
+	.init_client_instance = hclgevf_init_client_instance,
+	.uninit_client_instance = hclgevf_uninit_client_instance,
 	.start = hclgevf_ae_start,
 	.stop = hclgevf_ae_stop,
 	.map_ring_to_vector = hclgevf_map_ring_to_vector,
-- 
2.9.3

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox