* Re: [PATCH V2 1/4] net-next: dsa: move struct dsa_device_ops to the global header file
From: Andrew Lunn @ 2017-07-26 14:53 UTC (permalink / raw)
To: John Crispin
Cc: Vivien Didelot, Florian Fainelli, David S . Miller, netdev,
linux-kernel
In-Reply-To: <20170721085813.30789-1-john@phrozen.org>
On Fri, Jul 21, 2017 at 10:58:10AM +0200, John Crispin wrote:
> We need to access this struct from within the flow_dissector to fix
> dissection for packets coming in on DSA devices.
>
> Signed-off-by: John Crispin <john@phrozen.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: TCP fast retransmit issues
From: Willy Tarreau @ 2017-07-26 14:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Klavs Klavsen, netdev
In-Reply-To: <1501079532.12695.17.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, Jul 26, 2017 at 07:32:12AM -0700, Eric Dumazet wrote:
> On Wed, 2017-07-26 at 15:42 +0200, Willy Tarreau wrote:
> > On Wed, Jul 26, 2017 at 06:31:21AM -0700, Eric Dumazet wrote:
> > > On Wed, 2017-07-26 at 14:18 +0200, Klavs Klavsen wrote:
> > > > the 192.168.32.44 is a Centos 7 box.
> > >
> > > Could you grab a capture on this box, to see if the bogus packets are
> > > sent by it, or later mangled by a middle box ?
> >
> > Given the huge difference between the window and the ranges of the
> > values in the SACK field, I'm pretty sure there's a firewall doing
> > some sequence numbers randomization in the middle, not aware of SACK
> > and not converting these ones. I've had to disable such broken
> > features more than once in field after similar observations! Probably
> > that the Mac doesn't advertise SACK support and doesn't experience the
> > problem.
>
> We need to check RFC if such invalid SACK blocks should be ignored (DUP
> ACK would be processed and trigger fast retransmit anyway), or strongly
> validated (as I suspect we currently do), leading to a total freeze.
RFC2883 #4.3 talks about interaction with PAWS and only suggests that
since the sequence numbers can wrap the sender should be aware that a
reported segment can in fact relate to a value within the prior seq
number space before cycling, but that they don't expect any side effect.
So that more or less means to me "you should consider that some of these
segments might be old, meaningless and should be ignored". But as you
can see the recommendation lacks a bit of strength given that no issue
was expected in such a situation.
Willy
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] net: dsa: lan9303: Fixed MDIO interface
From: Egil Hjelmeland @ 2017-07-26 14:50 UTC (permalink / raw)
To: Vivien Didelot, corbet, andrew, f.fainelli, davem, kernel,
linux-doc, linux-kernel, netdev
In-Reply-To: <87lgnbgtiq.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On 26. juli 2017 16:30, Vivien Didelot wrote:
> Hi Egil,
>
> Egil Hjelmeland <privat@egil-hjelmeland.no> writes:
>
>>> I'd suggest you to split up this one commit in several *atomic* and easy
>>> to review patches and send them separately as on thread named "net: dsa:
>>> lan9303: fix MDIO interface" (also note that imperative is prefered for
>>> subject lines, see: https://chris.beams.io/posts/git-commit/#imperative)
>>
>> I can split the first patch.
>>
>> I can also split the patch series to more digestible series. But
>> since most of the patches touches the same file, I assume that each
>> series must be completed and applied before starting on a new one.
>> So I really want to group the patches into only a few series in order
>> to not spend months on the process.
>
> I understand. But believe me, your patches are very likely to land
> mainline faster if you send them in small chunks. This might not be true
> for every subsystems, but netdev is very responsive. This is even more
> true since this series has no-no (such as the sysfs entries) which
> guarantees the whole patch series to be rejected.
>
> Sending portions of your local work branch then rebase it against
> net-next/master is a usual development process.
>
>
> Thanks,
>
> Vivien
>
Thank you for the advice. I got some other NMIs today that I have to
serve. Hope to come back with MDIO patch series soon.
Egil
^ permalink raw reply
* Re: TCP fast retransmit issues
From: Willy Tarreau @ 2017-07-26 14:38 UTC (permalink / raw)
To: Klavs Klavsen; +Cc: Eric Dumazet, netdev
In-Reply-To: <0b60368890bdb9aa1cf1df4bd0bf21cf@vsen.dk>
On Wed, Jul 26, 2017 at 04:25:29PM +0200, Klavs Klavsen wrote:
> Thank you very much guys for your insight.. its highly appreciated.
>
> Next up for me, is waiting till the network guys come back from summer
> vacation, and convince them to sniff on the devices in between to pinpoint
> the culprit :)
That said, Eric, I'm a bit surprized that it completely stalls. Shouldn't
the sender end up retransmitting unacked segments after seeing a certain
number of ACKs not making progress ? Or maybe this is disabled when SACKs
are in use but it seems to me that once invalid SACKs are ignored we should
ideally fall back to the normal way to deal with losses. Here the server
ACKed 3903858556 for the first time at 15:59:54.292743 and repeated this
one 850 times till 16:01:17.296407 but the client kept sending past this
point probably due to a huge window, so this looks suboptimal to me.
Willy
^ permalink raw reply
* Re: netlink: NULL timer crash
From: ChunYu Wang @ 2017-07-26 14:35 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzkaller, David Miller, Cong Wang, Eric Dumazet, Herbert Xu,
Alexei Starovoitov, netdev, LKML
In-Reply-To: <CACT4Y+b0+zHMCCzB=GZDe5_i7EMmkcuwH_Dis0bY-2gxf-+Vdg@mail.gmail.com>
Wo, thanks!
On Wed, Jul 26, 2017 at 9:13 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Wed, Jul 26, 2017 at 3:09 PM, <chunyu.wang.1995@gmail.com> wrote:
>> Hi Dmitry,
>>
>> By trying to apply your reproducer to normal kernels, this scenery can not
>> be reproduced (on fedora). Does this C source only for KASAN kernels?
>
> No, NULL derefs are detected without KASAN.
>
>
>> On Thursday, March 23, 2017 at 8:55:52 PM UTC+8, Dmitry Vyukov wrote:
>>>
>>> Hello,
>>>
>>> The following program triggers call of NULL timer func:
>>>
>>>
>>> https://gist.githubusercontent.com/dvyukov/c210d01c74b911273469a93862ea7788/raw/2a3182772a6a6e20af3e71c02c2a1c2895d803fb/gistfile1.txt
>>>
>>>
>>> BUG: unable to handle kernel NULL pointer dereference at (null)
>>> IP: (null)
>>> PGD 0
>>> Oops: 0010 [#1] SMP KASAN
>>> Modules linked in:
>>> CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.11.0-rc3+ #365
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
>>> 01/01/2011
>>> task: ffff88006c634300 task.stack: ffff88006c640000
>>> RIP: 0010: (null)
>>> RSP: 0018:ffff88006d1077c8 EFLAGS: 00010246
>>> RAX: dffffc0000000000 RBX: ffff880062bddb00 RCX: ffffffff8154e161
>>> RDX: 1ffffffff090c1f1 RSI: 0000000000000000 RDI: ffff880062bddb00
>>> RBP: ffff88006d1077e8 R08: fffffbfff0a936a8 R09: 0000000000000001
>>> R10: 0000000000000001 R11: fffffbfff0a936a7 R12: ffffffff84860f80
>>> R13: 0000000000000000 R14: ffff880062bddb60 R15: 1ffff1000da20f05
>>> FS: 0000000000000000(0000) GS:ffff88006d100000(0000)
>>> knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 0000000000000000 CR3: 0000000004e21000 CR4: 00000000001406e0
>>> Call Trace:
>>> <IRQ>
>>> neigh_timer_handler+0x365/0xd40 net/core/neighbour.c:944
>>> call_timer_fn+0x232/0x8c0 kernel/time/timer.c:1268
>>> expire_timers kernel/time/timer.c:1307 [inline]
>>> __run_timers+0x6f7/0xbd0 kernel/time/timer.c:1601
>>> run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
>>> __do_softirq+0x2d6/0xb54 kernel/softirq.c:284
>>> invoke_softirq kernel/softirq.c:364 [inline]
>>> irq_exit+0x1b1/0x1e0 kernel/softirq.c:405
>>> exiting_irq arch/x86/include/asm/apic.h:657 [inline]
>>> smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:962
>>> apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:487
>>> RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:53
>>> RSP: 0018:ffff88006c647dc0 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff10
>>> RAX: dffffc0000000000 RBX: 1ffff1000d8c8fbb RCX: 0000000000000000
>>> RDX: 1ffffffff09d8ed4 RSI: 0000000000000001 RDI: ffffffff84ec76a0
>>> RBP: ffff88006c647dc0 R08: ffffed000d8c6861 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000000 R12: fffffbfff09d8ed2
>>> R13: ffff88006c647e78 R14: ffffffff84ec7690 R15: 0000000000000002
>>> </IRQ>
>>> arch_safe_halt arch/x86/include/asm/paravirt.h:98 [inline]
>>> default_idle+0xba/0x450 arch/x86/kernel/process.c:275
>>> arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:266
>>> default_idle_call+0x37/0x80 kernel/sched/idle.c:97
>>> cpuidle_idle_call kernel/sched/idle.c:155 [inline]
>>> do_idle+0x230/0x380 kernel/sched/idle.c:244
>>> cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:346
>>> start_secondary+0x2a7/0x340 arch/x86/kernel/smpboot.c:275
>>> start_cpu+0x14/0x14 arch/x86/kernel/head_64.S:306
>>> Code: Bad RIP value.
>>> RIP: (null) RSP: ffff88006d1077c8
>>> CR2: 0000000000000000
>>> ---[ end trace 845120b8a0d21411 ]---
>>>
>>> On commit 093b995e3b55a0ae0670226ddfcb05bfbf0099ae
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to syzkaller+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
--
CHUNYU WANG
ASSOCIATE QE
KERNEL ENG
^ permalink raw reply
* Re: TCP fast retransmit issues
From: Eric Dumazet @ 2017-07-26 14:32 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Klavs Klavsen, netdev
In-Reply-To: <20170726134242.GB1737@1wt.eu>
On Wed, 2017-07-26 at 15:42 +0200, Willy Tarreau wrote:
> On Wed, Jul 26, 2017 at 06:31:21AM -0700, Eric Dumazet wrote:
> > On Wed, 2017-07-26 at 14:18 +0200, Klavs Klavsen wrote:
> > > the 192.168.32.44 is a Centos 7 box.
> >
> > Could you grab a capture on this box, to see if the bogus packets are
> > sent by it, or later mangled by a middle box ?
>
> Given the huge difference between the window and the ranges of the
> values in the SACK field, I'm pretty sure there's a firewall doing
> some sequence numbers randomization in the middle, not aware of SACK
> and not converting these ones. I've had to disable such broken
> features more than once in field after similar observations! Probably
> that the Mac doesn't advertise SACK support and doesn't experience the
> problem.
We need to check RFC if such invalid SACK blocks should be ignored (DUP
ACK would be processed and trigger fast retransmit anyway), or strongly
validated (as I suspect we currently do), leading to a total freeze.
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] net: dsa: lan9303: Fixed MDIO interface
From: Vivien Didelot @ 2017-07-26 14:30 UTC (permalink / raw)
To: Egil Hjelmeland, corbet, andrew, f.fainelli, davem, kernel,
linux-doc, linux-kernel, netdev
In-Reply-To: <87999a6c-4ea8-ba4c-e2db-cdb37c1c8c8a@egil-hjelmeland.no>
Hi Egil,
Egil Hjelmeland <privat@egil-hjelmeland.no> writes:
>> I'd suggest you to split up this one commit in several *atomic* and easy
>> to review patches and send them separately as on thread named "net: dsa:
>> lan9303: fix MDIO interface" (also note that imperative is prefered for
>> subject lines, see: https://chris.beams.io/posts/git-commit/#imperative)
>
> I can split the first patch.
>
> I can also split the patch series to more digestible series. But
> since most of the patches touches the same file, I assume that each
> series must be completed and applied before starting on a new one.
> So I really want to group the patches into only a few series in order
> to not spend months on the process.
I understand. But believe me, your patches are very likely to land
mainline faster if you send them in small chunks. This might not be true
for every subsystems, but netdev is very responsive. This is even more
true since this series has no-no (such as the sysfs entries) which
guarantees the whole patch series to be rejected.
Sending portions of your local work branch then rebase it against
net-next/master is a usual development process.
Thanks,
Vivien
^ permalink raw reply
* Re: TCP fast retransmit issues
From: Klavs Klavsen @ 2017-07-26 14:25 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Eric Dumazet, netdev
In-Reply-To: <20170726141847.GC1737@1wt.eu>
Thank you very much guys for your insight.. its highly appreciated.
Next up for me, is waiting till the network guys come back from summer
vacation, and convince them to sniff on the devices in between to
pinpoint the culprit :)
Willy Tarreau skrev den 2017-07-26 16:18:
> On Wed, Jul 26, 2017 at 04:08:19PM +0200, Klavs Klavsen wrote:
>> Grabbed on both ends.
>>
>> http://blog.klavsen.info/fast-retransmit-problem-junos-linux (updated
>> to new
>> dump - from client scp'ing)
>> http://blog.klavsen.info/fast-retransmit-problem-junos-linux-receiving-side
>> (receiving host)
>
> So bingo, Eric guessed right, the client's sequence numbers are
> translated
> on their way to/from the server, but the SACK fields are not :
>
> Server :
> 15:59:54.292867 IP (tos 0x8, ttl 64, id 15878, offset 0, flags [DF],
> proto TCP (6), length 64)
> 192.168.32.44.22 > 62.242.222.50.35002: Flags [.], cksum 0xfe2b
> (incorrect -> 0xce0e), seq 1568063538, ack 3903858556,
> win 10965, options [nop,nop,TS val 529899820 ecr
> 774272020,nop,nop,sack 1 {3903859904:3903861252}], length 0
>
> Client :
> 15:59:54.297388 IP (tos 0x8, ttl 56, id 15878, offset 0, flags [DF],
> proto TCP (6), length 64)
> 192.168.32.44.22 > 62.242.222.50.35002: Flags [.], cksum 0xbb2c
> (correct), seq 1568063538, ack 2684453645,
> win 10965, options [nop,nop,TS val 529899820 ecr
> 774272020,nop,nop,sack 1 {3903859904:3903861252}], length 0
>
> To there's very likely a broken firewall in the middle that is waiting
> for
> a bug fix, or to have its feature disabled. Sometimes it can also
> happen
> on firewalls performing some SYN proxying except that it would mangle
> the
> server's sequence numbers instead of the client ones.
>
> Willy
--
Regards,
Klavs Klavsen, GSEC - kl@vsen.dk - http://blog.klavsen.info - Tlf.
61281200
"Those who do not understand Unix are condemned to reinvent it, poorly."
--Henry Spencer
^ permalink raw reply
* Re: TCP fast retransmit issues
From: Willy Tarreau @ 2017-07-26 14:18 UTC (permalink / raw)
To: Klavs Klavsen; +Cc: Eric Dumazet, netdev
In-Reply-To: <fd335e0a0c914b9c42a754da2d24b1c3@vsen.dk>
On Wed, Jul 26, 2017 at 04:08:19PM +0200, Klavs Klavsen wrote:
> Grabbed on both ends.
>
> http://blog.klavsen.info/fast-retransmit-problem-junos-linux (updated to new
> dump - from client scp'ing)
> http://blog.klavsen.info/fast-retransmit-problem-junos-linux-receiving-side
> (receiving host)
So bingo, Eric guessed right, the client's sequence numbers are translated
on their way to/from the server, but the SACK fields are not :
Server :
15:59:54.292867 IP (tos 0x8, ttl 64, id 15878, offset 0, flags [DF], proto TCP (6), length 64)
192.168.32.44.22 > 62.242.222.50.35002: Flags [.], cksum 0xfe2b (incorrect -> 0xce0e), seq 1568063538, ack 3903858556,
win 10965, options [nop,nop,TS val 529899820 ecr 774272020,nop,nop,sack 1 {3903859904:3903861252}], length 0
Client :
15:59:54.297388 IP (tos 0x8, ttl 56, id 15878, offset 0, flags [DF], proto TCP (6), length 64)
192.168.32.44.22 > 62.242.222.50.35002: Flags [.], cksum 0xbb2c (correct), seq 1568063538, ack 2684453645,
win 10965, options [nop,nop,TS val 529899820 ecr 774272020,nop,nop,sack 1 {3903859904:3903861252}], length 0
To there's very likely a broken firewall in the middle that is waiting for
a bug fix, or to have its feature disabled. Sometimes it can also happen
on firewalls performing some SYN proxying except that it would mangle the
server's sequence numbers instead of the client ones.
Willy
^ permalink raw reply
* Re: [patch net-next 2/2] mlxsw: spectrum: Add support for access cable info via ethtool
From: Andrew Lunn @ 2017-07-26 14:18 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, idosch, arkadis, mlxsw
In-Reply-To: <20170614072740.1243-3-jiri@resnulli.us>
> +static int mlxsw_sp_get_module_info(struct net_device *netdev,
> + struct ethtool_modinfo *modinfo)
> +{
> + struct mlxsw_sp_port *mlxsw_sp_port = netdev_priv(netdev);
> + u8 module_info[MLXSW_SP_EEPROM_MODULE_INFO_SIZE];
> + u8 module_rev_id, module_id;
> + unsigned int read_size;
> + int err;
> +
> + err = mlxsw_sp_query_module_eeprom(mlxsw_sp_port, 0,
> + MLXSW_SP_EEPROM_MODULE_INFO_SIZE,
> + module_info, &read_size);
> + if (err)
> + return err;
> +
> + if (read_size < MLXSW_SP_EEPROM_MODULE_INFO_SIZE)
> + return -EIO;
> +
> + module_rev_id = module_info[MLXSW_SP_EEPROM_MODULE_INFO_REV_ID];
> + module_id = module_info[MLXSW_SP_EEPROM_MODULE_INFO_ID];
> +
> + switch (module_id) {
> + case MLXSW_SP_EEPROM_MODULE_INFO_ID_QSFP:
> + modinfo->type = ETH_MODULE_SFF_8436;
> + modinfo->eeprom_len = ETH_MODULE_SFF_8436_LEN;
> + break;
> + case MLXSW_SP_EEPROM_MODULE_INFO_ID_QSFP_PLUS:
> + case MLXSW_SP_EEPROM_MODULE_INFO_ID_QSFP28:
> + if (module_id == MLXSW_SP_EEPROM_MODULE_INFO_ID_QSFP28 ||
> + module_rev_id >= MLXSW_SP_EEPROM_MODULE_INFO_REV_ID_8636) {
> + modinfo->type = ETH_MODULE_SFF_8636;
> + modinfo->eeprom_len = ETH_MODULE_SFF_8636_LEN;
> + } else {
> + modinfo->type = ETH_MODULE_SFF_8436;
> + modinfo->eeprom_len = ETH_MODULE_SFF_8436_LEN;
> + }
> + break;
> + case MLXSW_SP_EEPROM_MODULE_INFO_ID_SFP:
> + modinfo->type = ETH_MODULE_SFF_8472;
> + modinfo->eeprom_len = ETH_MODULE_SFF_8472_LEN;
> + break;
> + default:
> + return -EINVAL;
Hi Jiri
I remember seeing a few different implementations of this function in
various drivers. Could you pull it out into a helper, passing in the
array of bytes and mod info? bnxt, mlx4, mlx5, igb, ixgbe and sfc
could then use the helper.
Andrew
^ permalink raw reply
* Re: TCP fast retransmit issues
From: Klavs Klavsen @ 2017-07-26 14:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1501075881.12695.15.camel@edumazet-glaptop3.roam.corp.google.com>
Grabbed on both ends.
http://blog.klavsen.info/fast-retransmit-problem-junos-linux (updated to
new dump - from client scp'ing)
http://blog.klavsen.info/fast-retransmit-problem-junos-linux-receiving-side
(receiving host)
Eric Dumazet skrev den 2017-07-26 15:31:
> On Wed, 2017-07-26 at 14:18 +0200, Klavs Klavsen wrote:
>> the 192.168.32.44 is a Centos 7 box.
>
> Could you grab a capture on this box, to see if the bogus packets are
> sent by it, or later mangled by a middle box ?
>
[CUT]
> 3012336703:3012338051 is clearly outside of the window.
> Receiver claims to have received bytes that were never sent.
>
Thank you very much..
[CUT]
--
Regards,
Klavs Klavsen, GSEC - kl@vsen.dk - http://blog.klavsen.info - Tlf.
61281200
"Those who do not understand Unix are condemned to reinvent it, poorly."
--Henry Spencer
^ permalink raw reply
* Re: [BUG] /net/hsr: prune_timer
From: Dmitry @ 2017-07-26 14:06 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev@vger.kernel.org
In-Reply-To: <CAM_iQpX96_Q_dQdoC4kEN4DXjmYgjgoLJY7JeT9qx_oLj++ZWg@mail.gmail.com>
> On Tue, Jul 18, 2017 at 1:07 AM, Dmitry <d.andreev@uni-eng.ru> wrote:
>> Hello!
>>
>>
>> void hsr_prune_nodes(unsigned long data) called once by timer.
>>
>> hsr_prune_nodes must be called periodically every PRUNE_PERIOD (60s).
>>
>>
>>
>>
>> This code want be added to tail of hsr_prune_nodes function
>>
>> hsr->prune_timer.expires = jiffies + msecs_to_jiffies(PRUNE_PERIOD);
>> add_timer(&hsr->prune_timer);
>>
>> or
>>
>> mod_timer(&hsr->prune_timer, jiffies + msecs_to_jiffies(PRUNE_PERIOD));
>
> Please feel free to send a patch.
>
> You can follow this doc:
> https://www.kernel.org/doc/html/v4.11/process/submitting-patches.html
>
>
> Thanks!
Thanks!
But I`m not ready to patch because fixing this bug open way for this (I
wrote in another message, now I trying investigate this):
"I added
mod_timer(&hsr->prune_timer, jiffies + msecs_to_jiffies(PRUNE_PERIOD))
to end of hsr_prune_nodes function for periodically calling. I wrote
earlier that it looks like it's a bug.
HSR ring first time (some hours) works properly then works not stable.
After some hours situation become like this:
node1 ping
node 2 OK
node 3 OK
node 4 NO PING
node 5 OK
node 6 NO PING
node 7 NO PING
node 8 OK
and etc.
in same time nodeN ping
node 1 NO PING
node 2 OK
node 3 OK
node 4 OK
node 5 OK
node 6 NO PING
node 7 OK
node 8 NO PING
and etc
and ping result dynamcally changing and not similiar for each node.
Some thinking and tests:
I added debug code into hsr_forward_do function:
...
if (hsr_register_frame_out(port, frame->node_src,frame->sequence_nr))
{
//debug code
struct hsr_node *node = frame->node_src;
printk("\nhsr_forward_do(): registered frame dropped:
hsr_port_type:%d %x:%x:%x:%x:%x:%x %u\n", port->type,
node->MacAddressA[0], node->MacAddressA[1], node->MacAddressA[2],
node->MacAddressA[3], node->MacAddressA[4], node->MacAddressA[5],
frame->sequence_nr);
continue;
}
...
As usual frame passed for port->type == 1, port->type == 2 and one frame
for port->type == 4 passed, one frame for port->type == 4 dropped.
Sometime in limited period of time type == 1, type == 2 suddenly dropped
as already registered
For debug purpose I commented this part of code:
...
/*if (hsr_register_frame_out(port, frame->node_src,
frame->sequence_nr))
{
//debug code
struct hsr_node *node = frame->node_src;
printk("\nhsr_forward_do(): registered frame dropped:
hsr_port_type:%d %x:%x:%x:%x:%x:%x %u\n", port->type,
node->MacAddressA[0], node->MacAddressA[1], node->MacAddressA[2],
node->MacAddressA[3], node->MacAddressA[4], node->MacAddressA[5],
frame->sequence_nr);
continue;
}*/
...
and got stable ping on long time.
In this case of course there are dublicated frames and they are dropped on
IP protocol layer.
IMHO there are cumulative malfunction in code whitch manage list of nodes
and detect already processed frames."
^ permalink raw reply
* Re: TCP fast retransmit issues
From: Willy Tarreau @ 2017-07-26 13:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Klavs Klavsen, netdev
In-Reply-To: <1501075881.12695.15.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, Jul 26, 2017 at 06:31:21AM -0700, Eric Dumazet wrote:
> On Wed, 2017-07-26 at 14:18 +0200, Klavs Klavsen wrote:
> > the 192.168.32.44 is a Centos 7 box.
>
> Could you grab a capture on this box, to see if the bogus packets are
> sent by it, or later mangled by a middle box ?
Given the huge difference between the window and the ranges of the
values in the SACK field, I'm pretty sure there's a firewall doing
some sequence numbers randomization in the middle, not aware of SACK
and not converting these ones. I've had to disable such broken
features more than once in field after similar observations! Probably
that the Mac doesn't advertise SACK support and doesn't experience the
problem.
Willy
^ permalink raw reply
* Re: [PATCH net] Revert "vhost: cache used event for better performance"
From: Jason Wang @ 2017-07-26 13:37 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtualization, kvm, netdev, linux-kernel
In-Reply-To: <117542fc-eef9-c043-7c9e-daafceb7db4e@redhat.com>
On 2017年07月26日 21:18, Jason Wang wrote:
>
>
> On 2017年07月26日 20:57, Michael S. Tsirkin wrote:
>> On Wed, Jul 26, 2017 at 04:03:17PM +0800, Jason Wang wrote:
>>> This reverts commit 809ecb9bca6a9424ccd392d67e368160f8b76c92. Since it
>>> was reported to break vhost_net. We want to cache used event and use
>>> it to check for notification. We try to valid cached used event by
>>> checking whether or not it was ahead of new, but this is not correct
>>> all the time, it could be stale and there's no way to know about this.
>>>
>>> Signed-off-by: Jason Wang<jasowang@redhat.com>
>> Could you supply a bit more data here please? How does it get stale?
>> What does guest need to do to make it stale? This will be helpful if
>> anyone wants to bring it back, or if we want to extend the protocol.
>>
>
> The problem we don't know whether or not guest has published a new
> used event. The check vring_need_event(vq->last_used_event, new +
> vq->num, new) is not sufficient to check for this.
>
> Thanks
More notes, the previous assumption is that we don't move used event
back, but this could happen in fact if idx is wrapper around. Will
repost and add this into commit log.
Thanks
^ permalink raw reply
* Re: TCP fast retransmit issues
From: Eric Dumazet @ 2017-07-26 13:31 UTC (permalink / raw)
To: Klavs Klavsen; +Cc: netdev
In-Reply-To: <a025f5b2ed6e1f287f68b6bb5137a988@vsen.dk>
On Wed, 2017-07-26 at 14:18 +0200, Klavs Klavsen wrote:
> the 192.168.32.44 is a Centos 7 box.
Could you grab a capture on this box, to see if the bogus packets are
sent by it, or later mangled by a middle box ?
>
> Could you help me by elaborating on how to see why the "dup ack" (sack
> blocks) are bogus?
tcpdump -S ...
01:37:44.455158 IP 62.242.222.50.54004 > 192.168.32.44.22: Flags [.], seq 370328274:370329622, ack 4062374366, win 1382, options [nop,nop,TS val 769439585 ecr 510569974], length 1348
01:37:44.455159 IP 62.242.222.50.54004 > 192.168.32.44.22: Flags [.], seq 370329622:370330970, ack 4062374366, win 1382, options [nop,nop,TS val 769439585 ecr 510569974], length 1348
01:37:44.455160 IP 62.242.222.50.54004 > 192.168.32.44.22: Flags [.], seq 370330970:370332318, ack 4062374366, win 1382, options [nop,nop,TS val 769439585 ecr 510569974], length 1348
01:37:44.455160 IP 62.242.222.50.54004 > 192.168.32.44.22: Flags [.], seq 370332318:370333666, ack 4062374366, win 1382, options [nop,nop,TS val 769439585 ecr 510569974], length 1348
01:37:44.455163 IP 192.168.32.44.22 > 62.242.222.50.54004: Flags [.], ack 370166514, win 2730, options [nop,nop,TS val 510569975 ecr 769439578,nop,nop,sack 1 {3012336703:3012338051}], length 0
3012336703:3012338051 is clearly outside of the window.
Receiver claims to have received bytes that were never sent.
01:37:44.455169 IP 192.168.32.44.22 > 62.242.222.50.54004: Flags [.], ack 370166514, win 2730, options [nop,nop,TS val 510569975 ecr 769439578,nop,nop,sack 1 {3012336703:3012339399}], length 0
01:37:44.455172 IP 192.168.32.44.22 > 62.242.222.50.54004: Flags [.], ack 370166514, win 2730, options [nop,nop,TS val 510569975 ecr 769439578,nop,nop,sack 1 {3012336703:3012340747}], length 0
01:37:44.455175 IP 192.168.32.44.22 > 62.242.222.50.54004: Flags [.], ack 370166514, win 2730, options [nop,nop,TS val 510569975 ecr 769439578,nop,nop,sack 1 {3012336703:3012342095}], length 0
01:37:44.455178 IP 192.168.32.44.22 > 62.242.222.50.54004: Flags [.], ack 370166514, win 2730, options [nop,nop,TS val 510569975 ecr 769439578,nop,nop,sack 1 {3012336703:3012343443}], length 0
01:37:44.455181 IP 192.168.32.44.22 > 62.242.222.50.54004: Flags [.], ack 370166514, win 2730, options [nop,nop,TS val 510569976 ecr 769439578,nop,nop,sack 1 {3012336703:3012344791}], length 0
01:37:44.455183 IP 192.168.32.44.22 > 62.242.222.50.54004: Flags [.], ack 370166514, win 2730, options [nop,nop,TS val 510569976 ecr 769439578,nop,nop,sack 1 {3012336703:3012346139}], length 0
01:37:44.455186 IP 192.168.32.44.22 > 62.242.222.50.54004: Flags [.], ack 370166514, win 2730, options [nop,nop,TS val 510569976 ecr 769439578,nop,nop,sack 1 {3012336703:3012347487}], length 0
01:37:44.455189 IP 192.168.32.44.22 > 62.242.222.50.54004: Flags [.], ack 370166514, win 2730, options [nop,nop,TS val 510569977 ecr 769439578,nop,nop,sack 1 {3012336703:3012348835}], length 0
>
> Thank you very much. I'll try to capture the same scp done on mac - and
> see if it also gets DUP ACK's - and how they look in comparison (since
> it works on Mac clients).
>
> Eric Dumazet skrev den 2017-07-26 13:49:
> > On Wed, 2017-07-26 at 13:07 +0200, Klavs Klavsen wrote:
> >> Hi guys,
> >>
> >> Me and my colleagues have an annoying issue with our Linux desktops
> >> and
> >> the company's Junos VPN.
> >>
> >> We connect with openconnect (some use the official Pulse client) -
> >> which
> >> then opens up a tun0 device - and traffic runs through that.
> >>
> >> If we try to scp a file of ~100MB (f.ex. linux-4.12.3.tar.xz :) - it
> >> stalls after sending 20-30% typicly.. then starts again after some
> >> time,
> >> and typicly dies before finishing. I've captured it with tcpdump (its
> >> a
> >> large 77Mb file - thats how far it got before it died :) -
> >> http://blog.klavsen.info/fast-retransmit-problem-junos-linux
> >>
> >> I've attached an image of wireshark - where the (AFAIK) interesting
> >> part
> >> starts.. Where my client starts getting DUP ACK's.. but my Linux
> >> client
> >> does nothing :(
> >> I've tried to upgrade to latest Ubuntu-mainline kernel build (4.12.3)
> >> and it changed nothing.
> >>
> >> The problem goes away, if I do:
> >> sysctl -w net.ipv4.tcp_sack=0
> >>
> >> I've tried specificly enabling net.ipv4.tcp_fack=1 - but that did not
> >> help.
> >>
> >> This is not an issue on Mac OSX or Windows clients.
> >>
> >> None of the Linux users here figured, that could be a Linux kernel
> >> issue
> >> - but the evidence seems to suggest it - and all my googleing and
> >> reading does not lead me to any other conclusion.
> >>
> >> It may ofcourse be that Junos has implemented the standard
> >> badly/wrongly
> >> - and Windows/Mac has done a workaround for that?
> >>
> >> I hope you can help me figure out whats going wrong.
> >>
> >
> > sack blocks returned by the remote peer are completely bogus.
> >
> > Maybe a firewall is messing with them ?
> >
> > I suspect ACK packets might be simply dropped because of invalid SACK
> > information.
>
^ permalink raw reply
* Re: [PATCH net-next 2/2] bnxt_en: define sriov_lock unconditionally
From: Arnd Bergmann @ 2017-07-26 13:18 UTC (permalink / raw)
To: Sathya Perla
Cc: Michael Chan, David S. Miller, Somnath Kotur, Deepak Khungar,
Netdev, open list
In-Reply-To: <CAKvpyk3hyoAj0w9v1ZDfBs=8s4c=3kbDT8ZpDEUTb1yJnRvzuA@mail.gmail.com>
On Wed, Jul 26, 2017 at 12:54 PM, Sathya Perla
<sathya.perla@broadcom.com> wrote:
> On Wed, Jul 26, 2017 at 2:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> [...]
>>> Sathya already sent 3 patches to fix some of these issues. But I need
>>> to rework one of his patch and resend.
>>
>> Ok, thanks. I just ran into one more issue, and don't know if that's included
>> as well. If not, please also add the patch below (or fold it into the one
>> that adds the switchdev dependency to the ethernet driver):
>>
>> 8<----------
>> Subject: [PATCH] RDMA/bnxt_re: add NET_SWITCHDEV dependency
>>
>> The rdma side of BNXT enables the ethernet driver and has a list
>> of its dependencies. However, the ethernet driver now also depends
>> on NET_SWITCHDEV, so we have to add that dependency for both:
>
> Arnd, after the patch "bnxt_en: use SWITCHDEV_SET_OPS() for setting
> vf_rep_switchdev_ops" the bnxt_en driver doesn't need an explicit
> NET_SWITCHDEV dependency. So, the bnxt_re driver shouldn't need one
> either. Are you still seeing the bnxt_re issue even after pulling the
> above patch??
I think that's fine then. I missed that patch when it went in, so I only
needed the add-on since I still had my own earlier patch. I'll drop both
from my test tree now, and will let you know in case something else
remains.
Arnd
^ permalink raw reply
* Re: linux-next: Tree for Jul 26
From: Sergey Senozhatsky @ 2017-07-26 13:18 UTC (permalink / raw)
To: Rosen, Rami
Cc: Sergey Senozhatsky, Paolo Abeni, Stephen Rothwell,
Linux-Next Mailing List, Linux Kernel Mailing List, Paul Moore,
David S. Miller, netdev@vger.kernel.org
In-Reply-To: <9B0331B6EBBD0E4684FBFAEDA55776F93DA513FA@HASMSX110.ger.corp.intel.com>
Hello,
On (07/26/17 13:09), Rosen, Rami wrote:
> Hi Sergey,
> Paolo Abeni had sent a patch:
> https://www.mail-archive.com/netdev@vger.kernel.org/msg179192.html
yep, this should do the trick. thanks.
-ss
^ permalink raw reply
* Re: [PATCH net] Revert "vhost: cache used event for better performance"
From: Jason Wang @ 2017-07-26 13:18 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtualization, kvm, netdev, linux-kernel
In-Reply-To: <20170726155435-mutt-send-email-mst@kernel.org>
On 2017年07月26日 20:57, Michael S. Tsirkin wrote:
> On Wed, Jul 26, 2017 at 04:03:17PM +0800, Jason Wang wrote:
>> This reverts commit 809ecb9bca6a9424ccd392d67e368160f8b76c92. Since it
>> was reported to break vhost_net. We want to cache used event and use
>> it to check for notification. We try to valid cached used event by
>> checking whether or not it was ahead of new, but this is not correct
>> all the time, it could be stale and there's no way to know about this.
>>
>> Signed-off-by: Jason Wang<jasowang@redhat.com>
> Could you supply a bit more data here please? How does it get stale?
> What does guest need to do to make it stale? This will be helpful if
> anyone wants to bring it back, or if we want to extend the protocol.
>
The problem we don't know whether or not guest has published a new used
event. The check vring_need_event(vq->last_used_event, new + vq->num,
new) is not sufficient to check for this.
Thanks
^ permalink raw reply
* Re: [PATCH net] sctp: fix the check for _sctp_walk_params and _sctp_walk_errors
From: Neil Horman @ 2017-07-26 13:14 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner, glider
In-Reply-To: <81a6fb647ad305525c840eae623c41b7ba52c975.1501057499.git.lucien.xin@gmail.com>
On Wed, Jul 26, 2017 at 04:24:59PM +0800, Xin Long wrote:
> Commit b1f5bfc27a19 ("sctp: don't dereference ptr before leaving
> _sctp_walk_{params, errors}()") tried to fix the issue that it
> may overstep the chunk end for _sctp_walk_{params, errors} with
> 'chunk_end > offset(length) + sizeof(length)'.
>
> But it introduced a side effect: When processing INIT, it verifies
> the chunks with 'param.v == chunk_end' after iterating all params
> by sctp_walk_params(). With the check 'chunk_end > offset(length)
> + sizeof(length)', it would return when the last param is not yet
> accessed. Because the last param usually is fwdtsn supported param
> whose size is 4 and 'chunk_end == offset(length) + sizeof(length)'
>
> This is a badly issue even causing sctp couldn't process 4-shakes.
> Client would always get abort when connecting to server, due to
> the failure of INIT chunk verification on server.
>
> The patch is to use 'chunk_end <= offset(length) + sizeof(length)'
> instead of 'chunk_end < offset(length) + sizeof(length)' for both
> _sctp_walk_params and _sctp_walk_errors.
>
> Fixes: b1f5bfc27a19 ("sctp: don't dereference ptr before leaving _sctp_walk_{params, errors}()")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> include/net/sctp/sctp.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index 980807d..45fd4c6 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -469,7 +469,7 @@ _sctp_walk_params((pos), (chunk), ntohs((chunk)->chunk_hdr.length), member)
>
> #define _sctp_walk_params(pos, chunk, end, member)\
> for (pos.v = chunk->member;\
> - (pos.v + offsetof(struct sctp_paramhdr, length) + sizeof(pos.p->length) <\
> + (pos.v + offsetof(struct sctp_paramhdr, length) + sizeof(pos.p->length) <=\
> (void *)chunk + end) &&\
> pos.v <= (void *)chunk + end - ntohs(pos.p->length) &&\
> ntohs(pos.p->length) >= sizeof(struct sctp_paramhdr);\
> @@ -481,7 +481,7 @@ _sctp_walk_errors((err), (chunk_hdr), ntohs((chunk_hdr)->length))
> #define _sctp_walk_errors(err, chunk_hdr, end)\
> for (err = (sctp_errhdr_t *)((void *)chunk_hdr + \
> sizeof(struct sctp_chunkhdr));\
> - ((void *)err + offsetof(sctp_errhdr_t, length) + sizeof(err->length) <\
> + ((void *)err + offsetof(sctp_errhdr_t, length) + sizeof(err->length) <=\
> (void *)chunk_hdr + end) &&\
> (void *)err <= (void *)chunk_hdr + end - ntohs(err->length) &&\
> ntohs(err->length) >= sizeof(sctp_errhdr_t); \
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: netlink: NULL timer crash
From: Dmitry Vyukov @ 2017-07-26 13:13 UTC (permalink / raw)
To: chunyu.wang.1995
Cc: syzkaller, David Miller, Cong Wang, Eric Dumazet, Herbert Xu,
Alexei Starovoitov, netdev, LKML
In-Reply-To: <380e2478-4251-47d5-833c-2be5437ab0f0@googlegroups.com>
On Wed, Jul 26, 2017 at 3:09 PM, <chunyu.wang.1995@gmail.com> wrote:
> Hi Dmitry,
>
> By trying to apply your reproducer to normal kernels, this scenery can not
> be reproduced (on fedora). Does this C source only for KASAN kernels?
No, NULL derefs are detected without KASAN.
> On Thursday, March 23, 2017 at 8:55:52 PM UTC+8, Dmitry Vyukov wrote:
>>
>> Hello,
>>
>> The following program triggers call of NULL timer func:
>>
>>
>> https://gist.githubusercontent.com/dvyukov/c210d01c74b911273469a93862ea7788/raw/2a3182772a6a6e20af3e71c02c2a1c2895d803fb/gistfile1.txt
>>
>>
>> BUG: unable to handle kernel NULL pointer dereference at (null)
>> IP: (null)
>> PGD 0
>> Oops: 0010 [#1] SMP KASAN
>> Modules linked in:
>> CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.11.0-rc3+ #365
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
>> 01/01/2011
>> task: ffff88006c634300 task.stack: ffff88006c640000
>> RIP: 0010: (null)
>> RSP: 0018:ffff88006d1077c8 EFLAGS: 00010246
>> RAX: dffffc0000000000 RBX: ffff880062bddb00 RCX: ffffffff8154e161
>> RDX: 1ffffffff090c1f1 RSI: 0000000000000000 RDI: ffff880062bddb00
>> RBP: ffff88006d1077e8 R08: fffffbfff0a936a8 R09: 0000000000000001
>> R10: 0000000000000001 R11: fffffbfff0a936a7 R12: ffffffff84860f80
>> R13: 0000000000000000 R14: ffff880062bddb60 R15: 1ffff1000da20f05
>> FS: 0000000000000000(0000) GS:ffff88006d100000(0000)
>> knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 0000000000000000 CR3: 0000000004e21000 CR4: 00000000001406e0
>> Call Trace:
>> <IRQ>
>> neigh_timer_handler+0x365/0xd40 net/core/neighbour.c:944
>> call_timer_fn+0x232/0x8c0 kernel/time/timer.c:1268
>> expire_timers kernel/time/timer.c:1307 [inline]
>> __run_timers+0x6f7/0xbd0 kernel/time/timer.c:1601
>> run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
>> __do_softirq+0x2d6/0xb54 kernel/softirq.c:284
>> invoke_softirq kernel/softirq.c:364 [inline]
>> irq_exit+0x1b1/0x1e0 kernel/softirq.c:405
>> exiting_irq arch/x86/include/asm/apic.h:657 [inline]
>> smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:962
>> apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:487
>> RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:53
>> RSP: 0018:ffff88006c647dc0 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff10
>> RAX: dffffc0000000000 RBX: 1ffff1000d8c8fbb RCX: 0000000000000000
>> RDX: 1ffffffff09d8ed4 RSI: 0000000000000001 RDI: ffffffff84ec76a0
>> RBP: ffff88006c647dc0 R08: ffffed000d8c6861 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000000 R12: fffffbfff09d8ed2
>> R13: ffff88006c647e78 R14: ffffffff84ec7690 R15: 0000000000000002
>> </IRQ>
>> arch_safe_halt arch/x86/include/asm/paravirt.h:98 [inline]
>> default_idle+0xba/0x450 arch/x86/kernel/process.c:275
>> arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:266
>> default_idle_call+0x37/0x80 kernel/sched/idle.c:97
>> cpuidle_idle_call kernel/sched/idle.c:155 [inline]
>> do_idle+0x230/0x380 kernel/sched/idle.c:244
>> cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:346
>> start_secondary+0x2a7/0x340 arch/x86/kernel/smpboot.c:275
>> start_cpu+0x14/0x14 arch/x86/kernel/head_64.S:306
>> Code: Bad RIP value.
>> RIP: (null) RSP: ffff88006d1077c8
>> CR2: 0000000000000000
>> ---[ end trace 845120b8a0d21411 ]---
>>
>> On commit 093b995e3b55a0ae0670226ddfcb05bfbf0099ae
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* RE: linux-next: Tree for Jul 26
From: Rosen, Rami @ 2017-07-26 13:09 UTC (permalink / raw)
To: Sergey Senozhatsky, Paolo Abeni, Stephen Rothwell
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Paul Moore,
David S. Miller, netdev@vger.kernel.org
In-Reply-To: <20170726104856.GA5755@jagdpanzerIV.localdomain>
Hi Sergey,
Paolo Abeni had sent a patch:
https://www.mail-archive.com/netdev@vger.kernel.org/msg179192.html
Regards,
Rami Rosen
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Sergey Senozhatsky
Sent: Wednesday, July 26, 2017 13:49
To: Paolo Abeni <pabeni@redhat.com>; Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Paul Moore <paul@paul-moore.com>; David S. Miller <davem@davemloft.net>; netdev@vger.kernel.org
Subject: Re: linux-next: Tree for Jul 26
Hello,
On (07/26/17 16:12), Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20170725:
>
> Non-merge commits (relative to Linus' tree): 2358
> 2466 files changed, 86994 insertions(+), 44655 deletions(-)
dce4551cb2adb1ac ("udp: preserve head state for IP_CMSG_PASSSEC") causes a build error
net/ipv4/udp.c: In function ‘__udp_queue_rcv_skb’:
net/ipv4/udp.c:1789:49: error: ‘struct sk_buff’ has no member named ‘sp’; did you mean ‘sk’?
if (likely(IPCB(skb)->opt.optlen == 0 && !skb->sp))
^
-ss
^ permalink raw reply
* [PATCH v2 net-next 6/7] qed: Read per queue coalesce from hardware
From: Manish Chopra @ 2017-07-26 13:07 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz, rahul.verma, sudarsana.kalluru, Rahul Verma
In-Reply-To: <20170726130715.12976-1-manish.chopra@cavium.com>
From: Rahul Verma <Rahul.Verma@cavium.com>
Retrieve the actual coalesce value from hardware for every Rx/Tx
queue, instead of Rx/Tx coalesce value cached during set coalesce.
Signed-off-by: Rahul Verma <Rahul.Verma@cavium.com>
Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dev_api.h | 26 ++++--
drivers/net/ethernet/qlogic/qed/qed_l2.c | 115 +++++++++++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_l2.h | 11 ++-
drivers/net/ethernet/qlogic/qed/qed_main.c | 7 --
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 74 +++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_sriov.h | 3 +
drivers/net/ethernet/qlogic/qed/qed_vf.c | 31 ++++++
drivers/net/ethernet/qlogic/qed/qed_vf.h | 29 ++++++-
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 47 ++++++++-
include/linux/qed/qed_eth_if.h | 1 +
include/linux/qed/qed_if.h | 11 +--
11 files changed, 324 insertions(+), 31 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev_api.h b/drivers/net/ethernet/qlogic/qed/qed_dev_api.h
index e6b3c83..defdda1 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev_api.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev_api.h
@@ -443,13 +443,25 @@ int qed_final_cleanup(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt, u16 id, bool is_vf);
/**
- * @brief qed_set_queue_coalesce - Configure coalesce parameters for Rx or
- * Tx queue. We can configure coalescing to up to 511, but on
- * varying accuracy [the bigger the value the less accurate] up to a mistake
- * of 3usec for the highest values.
- * While the API allows setting coalescing per-qid, all queues sharing a SB
- * should be in same range [i.e., either 0-0x7f, 0x80-0xff or 0x100-0x1ff]
- * otherwise configuration would break.
+ * @brief qed_get_queue_coalesce - Retrieve coalesce value for a given queue.
+ *
+ * @param p_hwfn
+ * @param p_coal - store coalesce value read from the hardware.
+ * @param p_handle
+ *
+ * @return int
+ **/
+int qed_get_queue_coalesce(struct qed_hwfn *p_hwfn, u16 *coal, void *handle);
+
+/**
+ * @brief qed_set_queue_coalesce - Configure coalesce parameters for Rx and
+ * Tx queue. The fact that we can configure coalescing to up to 511, but on
+ * varying accuracy [the bigger the value the less accurate] up to a mistake
+ * of 3usec for the highest values.
+ * While the API allows setting coalescing per-qid, all queues sharing a SB
+ * should be in same range [i.e., either 0-0x7f, 0x80-0xff or 0x100-0x1ff]
+ * otherwise configuration would break.
+ *
*
* @param rx_coal - Rx Coalesce value in micro seconds.
* @param tx_coal - TX Coalesce value in micro seconds.
diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index 0ba5ec8..9a16458 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -2047,6 +2047,106 @@ void qed_reset_vport_stats(struct qed_dev *cdev)
return qed_spq_post(p_hwfn, p_ent, NULL);
}
+int qed_get_rxq_coalesce(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ struct qed_queue_cid *p_cid, u16 *p_rx_coal)
+{
+ u32 coalesce, address, is_valid;
+ struct cau_sb_entry sb_entry;
+ u8 timer_res;
+ int rc;
+
+ rc = qed_dmae_grc2host(p_hwfn, p_ptt, CAU_REG_SB_VAR_MEMORY +
+ p_cid->sb_igu_id * sizeof(u64),
+ (u64)(uintptr_t)&sb_entry, 2, 0);
+ if (rc) {
+ DP_ERR(p_hwfn, "dmae_grc2host failed %d\n", rc);
+ return rc;
+ }
+
+ timer_res = GET_FIELD(sb_entry.params, CAU_SB_ENTRY_TIMER_RES0);
+
+ address = BAR0_MAP_REG_USDM_RAM +
+ USTORM_ETH_QUEUE_ZONE_OFFSET(p_cid->abs.queue_id);
+ coalesce = qed_rd(p_hwfn, p_ptt, address);
+
+ is_valid = GET_FIELD(coalesce, COALESCING_TIMESET_VALID);
+ if (!is_valid)
+ return -EINVAL;
+
+ coalesce = GET_FIELD(coalesce, COALESCING_TIMESET_TIMESET);
+ *p_rx_coal = (u16)(coalesce << timer_res);
+
+ return 0;
+}
+
+int qed_get_txq_coalesce(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ struct qed_queue_cid *p_cid, u16 *p_tx_coal)
+{
+ u32 coalesce, address, is_valid;
+ struct cau_sb_entry sb_entry;
+ u8 timer_res;
+ int rc;
+
+ rc = qed_dmae_grc2host(p_hwfn, p_ptt, CAU_REG_SB_VAR_MEMORY +
+ p_cid->sb_igu_id * sizeof(u64),
+ (u64)(uintptr_t)&sb_entry, 2, 0);
+ if (rc) {
+ DP_ERR(p_hwfn, "dmae_grc2host failed %d\n", rc);
+ return rc;
+ }
+
+ timer_res = GET_FIELD(sb_entry.params, CAU_SB_ENTRY_TIMER_RES1);
+
+ address = BAR0_MAP_REG_XSDM_RAM +
+ XSTORM_ETH_QUEUE_ZONE_OFFSET(p_cid->abs.queue_id);
+ coalesce = qed_rd(p_hwfn, p_ptt, address);
+
+ is_valid = GET_FIELD(coalesce, COALESCING_TIMESET_VALID);
+ if (!is_valid)
+ return -EINVAL;
+
+ coalesce = GET_FIELD(coalesce, COALESCING_TIMESET_TIMESET);
+ *p_tx_coal = (u16)(coalesce << timer_res);
+
+ return 0;
+}
+
+int qed_get_queue_coalesce(struct qed_hwfn *p_hwfn, u16 *p_coal, void *handle)
+{
+ struct qed_queue_cid *p_cid = handle;
+ struct qed_ptt *p_ptt;
+ int rc = 0;
+
+ if (IS_VF(p_hwfn->cdev)) {
+ rc = qed_vf_pf_get_coalesce(p_hwfn, p_coal, p_cid);
+ if (rc)
+ DP_NOTICE(p_hwfn, "Unable to read queue coalescing\n");
+
+ return rc;
+ }
+
+ p_ptt = qed_ptt_acquire(p_hwfn);
+ if (!p_ptt)
+ return -EAGAIN;
+
+ if (p_cid->b_is_rx) {
+ rc = qed_get_rxq_coalesce(p_hwfn, p_ptt, p_cid, p_coal);
+ if (rc)
+ goto out;
+ } else {
+ rc = qed_get_txq_coalesce(p_hwfn, p_ptt, p_cid, p_coal);
+ if (rc)
+ goto out;
+ }
+
+out:
+ qed_ptt_release(p_hwfn, p_ptt);
+
+ return rc;
+}
+
static int qed_fill_eth_dev_info(struct qed_dev *cdev,
struct qed_dev_eth_info *info)
{
@@ -2696,6 +2796,20 @@ static int qed_ntuple_arfs_filter_config(struct qed_dev *cdev, void *cookie,
return rc;
}
+static int qed_get_coalesce(struct qed_dev *cdev, u16 *coal, void *handle)
+{
+ struct qed_queue_cid *p_cid = handle;
+ struct qed_hwfn *p_hwfn;
+ int rc;
+
+ p_hwfn = p_cid->p_owner;
+ rc = qed_get_queue_coalesce(p_hwfn, coal, handle);
+ if (rc)
+ DP_NOTICE(p_hwfn, "Unable to read queue calescing\n");
+
+ return rc;
+}
+
static int qed_fp_cqe_completion(struct qed_dev *dev,
u8 rss_id, struct eth_slow_path_rx_cqe *cqe)
{
@@ -2739,6 +2853,7 @@ static int qed_fp_cqe_completion(struct qed_dev *dev,
.tunn_config = &qed_tunn_configure,
.ntuple_filter_config = &qed_ntuple_arfs_filter_config,
.configure_arfs_searcher = &qed_configure_arfs_searcher,
+ .get_coalesce = &qed_get_coalesce,
};
const struct qed_eth_ops *qed_get_eth_ops(void)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.h b/drivers/net/ethernet/qlogic/qed/qed_l2.h
index 60ea72c..cc1f248 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.h
@@ -407,4 +407,13 @@ int qed_set_rxq_coalesce(struct qed_hwfn *p_hwfn,
int qed_set_txq_coalesce(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt,
u16 coalesce, struct qed_queue_cid *p_cid);
-#endif /* _QED_L2_H */
+
+int qed_get_rxq_coalesce(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ struct qed_queue_cid *p_cid, u16 *p_hw_coal);
+
+int qed_get_txq_coalesce(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ struct qed_queue_cid *p_cid, u16 *p_hw_coal);
+
+#endif
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 448810a..2783288 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1568,12 +1568,6 @@ static int qed_nvm_get_image(struct qed_dev *cdev, enum qed_nvm_images type,
return rc;
}
-static void qed_get_coalesce(struct qed_dev *cdev, u16 *rx_coal, u16 *tx_coal)
-{
- *rx_coal = cdev->rx_coalesce_usecs;
- *tx_coal = cdev->tx_coalesce_usecs;
-}
-
static int qed_set_coalesce(struct qed_dev *cdev, u16 rx_coal, u16 tx_coal,
void *handle)
{
@@ -1726,7 +1720,6 @@ static int qed_update_mtu(struct qed_dev *cdev, u16 mtu)
.chain_alloc = &qed_chain_alloc,
.chain_free = &qed_chain_free,
.nvm_get_image = &qed_nvm_get_image,
- .get_coalesce = &qed_get_coalesce,
.set_coalesce = &qed_set_coalesce,
.set_led = &qed_set_led,
.update_drv_state = &qed_update_drv_state,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index 5feef78..3f40b1d 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -3400,6 +3400,75 @@ static void qed_iov_vf_mbx_release(struct qed_hwfn *p_hwfn,
length, status);
}
+static void qed_iov_vf_pf_get_coalesce(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ struct qed_vf_info *p_vf)
+{
+ struct qed_iov_vf_mbx *mbx = &p_vf->vf_mbx;
+ struct pfvf_read_coal_resp_tlv *p_resp;
+ struct vfpf_read_coal_req_tlv *req;
+ u8 status = PFVF_STATUS_FAILURE;
+ struct qed_vf_queue *p_queue;
+ struct qed_queue_cid *p_cid;
+ u16 coal = 0, qid, i;
+ bool b_is_rx;
+ int rc = 0;
+
+ mbx->offset = (u8 *)mbx->reply_virt;
+ req = &mbx->req_virt->read_coal_req;
+
+ qid = req->qid;
+ b_is_rx = req->is_rx ? true : false;
+
+ if (b_is_rx) {
+ if (!qed_iov_validate_rxq(p_hwfn, p_vf, qid,
+ QED_IOV_VALIDATE_Q_ENABLE)) {
+ DP_VERBOSE(p_hwfn, QED_MSG_IOV,
+ "VF[%d]: Invalid Rx queue_id = %d\n",
+ p_vf->abs_vf_id, qid);
+ goto send_resp;
+ }
+
+ p_cid = qed_iov_get_vf_rx_queue_cid(&p_vf->vf_queues[qid]);
+ rc = qed_get_rxq_coalesce(p_hwfn, p_ptt, p_cid, &coal);
+ if (rc)
+ goto send_resp;
+ } else {
+ if (!qed_iov_validate_txq(p_hwfn, p_vf, qid,
+ QED_IOV_VALIDATE_Q_ENABLE)) {
+ DP_VERBOSE(p_hwfn, QED_MSG_IOV,
+ "VF[%d]: Invalid Tx queue_id = %d\n",
+ p_vf->abs_vf_id, qid);
+ goto send_resp;
+ }
+ for (i = 0; i < MAX_QUEUES_PER_QZONE; i++) {
+ p_queue = &p_vf->vf_queues[qid];
+ if ((!p_queue->cids[i].p_cid) ||
+ (!p_queue->cids[i].b_is_tx))
+ continue;
+
+ p_cid = p_queue->cids[i].p_cid;
+
+ rc = qed_get_txq_coalesce(p_hwfn, p_ptt, p_cid, &coal);
+ if (rc)
+ goto send_resp;
+ break;
+ }
+ }
+
+ status = PFVF_STATUS_SUCCESS;
+
+send_resp:
+ p_resp = qed_add_tlv(p_hwfn, &mbx->offset, CHANNEL_TLV_COALESCE_READ,
+ sizeof(*p_resp));
+ p_resp->coal = coal;
+
+ qed_add_tlv(p_hwfn, &mbx->offset, CHANNEL_TLV_LIST_END,
+ sizeof(struct channel_list_end_tlv));
+
+ qed_iov_send_response(p_hwfn, p_ptt, p_vf, sizeof(*p_resp), status);
+}
+
static void qed_iov_vf_pf_set_coalesce(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt,
struct qed_vf_info *vf)
@@ -3450,6 +3519,7 @@ static void qed_iov_vf_pf_set_coalesce(struct qed_hwfn *p_hwfn,
vf->abs_vf_id, vf->vf_queues[qid].fw_rx_qid);
goto out;
}
+ vf->rx_coal = rx_coal;
}
if (tx_coal) {
@@ -3473,6 +3543,7 @@ static void qed_iov_vf_pf_set_coalesce(struct qed_hwfn *p_hwfn,
goto out;
}
}
+ vf->tx_coal = tx_coal;
}
status = PFVF_STATUS_SUCCESS;
@@ -3808,6 +3879,9 @@ static void qed_iov_process_mbx_req(struct qed_hwfn *p_hwfn,
case CHANNEL_TLV_COALESCE_UPDATE:
qed_iov_vf_pf_set_coalesce(p_hwfn, p_ptt, p_vf);
break;
+ case CHANNEL_TLV_COALESCE_READ:
+ qed_iov_vf_pf_get_coalesce(p_hwfn, p_ptt, p_vf);
+ break;
}
} else if (qed_iov_tlv_supported(mbx->first_tlv.tl.type)) {
DP_VERBOSE(p_hwfn, QED_MSG_IOV,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.h b/drivers/net/ethernet/qlogic/qed/qed_sriov.h
index c2e44bc..3955929 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.h
@@ -217,6 +217,9 @@ struct qed_vf_info {
u8 num_rxqs;
u8 num_txqs;
+ u16 rx_coal;
+ u16 tx_coal;
+
u8 num_sbs;
u8 num_mac_filters;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.c b/drivers/net/ethernet/qlogic/qed/qed_vf.c
index 0a7bbc0..91b5e9f 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.c
@@ -1343,6 +1343,37 @@ int qed_vf_pf_int_cleanup(struct qed_hwfn *p_hwfn)
return rc;
}
+int qed_vf_pf_get_coalesce(struct qed_hwfn *p_hwfn,
+ u16 *p_coal, struct qed_queue_cid *p_cid)
+{
+ struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
+ struct pfvf_read_coal_resp_tlv *resp;
+ struct vfpf_read_coal_req_tlv *req;
+ int rc;
+
+ /* clear mailbox and prep header tlv */
+ req = qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_COALESCE_READ, sizeof(*req));
+ req->qid = p_cid->rel.queue_id;
+ req->is_rx = p_cid->b_is_rx ? 1 : 0;
+
+ qed_add_tlv(p_hwfn, &p_iov->offset, CHANNEL_TLV_LIST_END,
+ sizeof(struct channel_list_end_tlv));
+ resp = &p_iov->pf2vf_reply->read_coal_resp;
+
+ rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, sizeof(*resp));
+ if (rc)
+ goto exit;
+
+ if (resp->hdr.status != PFVF_STATUS_SUCCESS)
+ goto exit;
+
+ *p_coal = resp->coal;
+exit:
+ qed_vf_pf_req_end(p_hwfn, rc);
+
+ return rc;
+}
+
int
qed_vf_pf_set_coalesce(struct qed_hwfn *p_hwfn,
u16 rx_coal, u16 tx_coal, struct qed_queue_cid *p_cid)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.h b/drivers/net/ethernet/qlogic/qed/qed_vf.h
index 2d9fdd6..97d44df 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.h
@@ -504,6 +504,20 @@ struct vfpf_update_coalesce {
u16 qid;
u8 padding[2];
};
+
+struct vfpf_read_coal_req_tlv {
+ struct vfpf_first_tlv first_tlv;
+ u16 qid;
+ u8 is_rx;
+ u8 padding[5];
+};
+
+struct pfvf_read_coal_resp_tlv {
+ struct pfvf_tlv hdr;
+ u16 coal;
+ u8 padding[6];
+};
+
union vfpf_tlvs {
struct vfpf_first_tlv first_tlv;
struct vfpf_acquire_tlv acquire;
@@ -517,7 +531,7 @@ struct vfpf_update_coalesce {
struct vfpf_ucast_filter_tlv ucast_filter;
struct vfpf_update_tunn_param_tlv tunn_param_update;
struct vfpf_update_coalesce update_coalesce;
- struct channel_list_end_tlv list_end;
+ struct vfpf_read_coal_req_tlv read_coal_req;
struct tlv_buffer_size tlv_buf_size;
};
@@ -527,6 +541,7 @@ struct vfpf_update_coalesce {
struct tlv_buffer_size tlv_buf_size;
struct pfvf_start_queue_resp_tlv queue_start;
struct pfvf_update_tunn_param_tlv tunn_param_resp;
+ struct pfvf_read_coal_resp_tlv read_coal_resp;
};
enum qed_bulletin_bit {
@@ -634,6 +649,7 @@ enum {
CHANNEL_TLV_UPDATE_TUNN_PARAM,
CHANNEL_TLV_COALESCE_UPDATE,
CHANNEL_TLV_QID,
+ CHANNEL_TLV_COALESCE_READ,
CHANNEL_TLV_MAX,
/* Required for iterating over vport-update tlvs.
@@ -699,6 +715,17 @@ int qed_vf_pf_set_coalesce(struct qed_hwfn *p_hwfn,
u16 rx_coal,
u16 tx_coal, struct qed_queue_cid *p_cid);
+/**
+ * @brief VF - Get coalesce per VF's relative queue.
+ *
+ * @param p_hwfn
+ * @param p_coal - coalesce value in micro second for VF queues.
+ * @param p_cid - queue cid
+ *
+ **/
+int qed_vf_pf_get_coalesce(struct qed_hwfn *p_hwfn,
+ u16 *p_coal, struct qed_queue_cid *p_cid);
+
#ifdef CONFIG_QED_SRIOV
/**
* @brief Read the VF bulletin and act on it if needed
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index 76e0b13..dae7412 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -702,16 +702,53 @@ static u32 qede_get_link(struct net_device *dev)
static int qede_get_coalesce(struct net_device *dev,
struct ethtool_coalesce *coal)
{
+ void *rx_handle = NULL, *tx_handle = NULL;
struct qede_dev *edev = netdev_priv(dev);
- u16 rxc, txc;
+ u16 rx_coal, tx_coal, i, rc = 0;
+ struct qede_fastpath *fp;
+
+ rx_coal = QED_DEFAULT_RX_USECS;
+ tx_coal = QED_DEFAULT_TX_USECS;
memset(coal, 0, sizeof(struct ethtool_coalesce));
- edev->ops->common->get_coalesce(edev->cdev, &rxc, &txc);
- coal->rx_coalesce_usecs = rxc;
- coal->tx_coalesce_usecs = txc;
+ __qede_lock(edev);
+ if (edev->state == QEDE_STATE_OPEN) {
+ for_each_queue(i) {
+ fp = &edev->fp_array[i];
+
+ if (fp->type & QEDE_FASTPATH_RX) {
+ rx_handle = fp->rxq->handle;
+ break;
+ }
+ }
- return 0;
+ rc = edev->ops->get_coalesce(edev->cdev, &rx_coal, rx_handle);
+ if (rc) {
+ DP_INFO(edev, "Read Rx coalesce error\n");
+ goto out;
+ }
+
+ for_each_queue(i) {
+ fp = &edev->fp_array[i];
+ if (fp->type & QEDE_FASTPATH_TX) {
+ tx_handle = fp->txq->handle;
+ break;
+ }
+ }
+
+ rc = edev->ops->get_coalesce(edev->cdev, &tx_coal, tx_handle);
+ if (rc)
+ DP_INFO(edev, "Read Tx coalesce error\n");
+ }
+
+out:
+ __qede_unlock(edev);
+
+ coal->rx_coalesce_usecs = rx_coal;
+ coal->tx_coalesce_usecs = tx_coal;
+
+ return rc;
}
static int qede_set_coalesce(struct net_device *dev,
diff --git a/include/linux/qed/qed_eth_if.h b/include/linux/qed/qed_eth_if.h
index 0eef0a2..d60de4a 100644
--- a/include/linux/qed/qed_eth_if.h
+++ b/include/linux/qed/qed_eth_if.h
@@ -323,6 +323,7 @@ struct qed_eth_ops {
int (*configure_arfs_searcher)(struct qed_dev *cdev,
bool en_searcher);
+ int (*get_coalesce)(struct qed_dev *cdev, u16 *coal, void *handle);
};
const struct qed_eth_ops *qed_get_eth_ops(void);
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index 4d59ca1..2b4720b 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -186,6 +186,7 @@ enum qed_led_mode {
#define QED_COALESCE_MAX 0xFF
#define QED_DEFAULT_RX_USECS 12
+#define QED_DEFAULT_TX_USECS 48
/* forward */
struct qed_dev;
@@ -674,16 +675,6 @@ struct qed_common_ops {
enum qed_nvm_images type, u8 *buf, u16 len);
/**
- * @brief get_coalesce - Get coalesce parameters in usec
- *
- * @param cdev
- * @param rx_coal - Rx coalesce value in usec
- * @param tx_coal - Tx coalesce value in usec
- *
- */
- void (*get_coalesce)(struct qed_dev *cdev, u16 *rx_coal, u16 *tx_coal);
-
-/**
* @brief set_coalesce - Configure Rx coalesce value in usec
*
* @param cdev
--
1.7.1
^ permalink raw reply related
* [PATCH v2 net-next 5/7] qed: Add support for vf coalesce configuration.
From: Manish Chopra @ 2017-07-26 13:07 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz, rahul.verma, sudarsana.kalluru, Rahul Verma
In-Reply-To: <20170726130715.12976-1-manish.chopra@cavium.com>
From: Rahul Verma <Rahul.Verma@cavium.com>
This patch add the ethtool support to set RX/Tx coalesce
value to the VF associated Rx/Tx queues.
Signed-off-by: Rahul Verma <Rahul.Verma@cavium.com>
Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 73 +++++++++++++-------
drivers/net/ethernet/qlogic/qed/qed_dev_api.h | 41 ++++--------
drivers/net/ethernet/qlogic/qed/qed_l2.h | 7 ++
drivers/net/ethernet/qlogic/qed/qed_main.c | 24 +------
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 83 +++++++++++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_vf.c | 44 ++++++++++++
drivers/net/ethernet/qlogic/qed/qed_vf.h | 24 ++++++-
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 38 ++++++++---
include/linux/qed/qed_if.h | 4 +-
9 files changed, 251 insertions(+), 87 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index f545607..58a689f 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -3694,7 +3694,7 @@ static int qed_set_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
}
p_coal_timeset = p_eth_qzone;
- memset(p_coal_timeset, 0, eth_qzone_size);
+ memset(p_eth_qzone, 0, eth_qzone_size);
SET_FIELD(p_coal_timeset->value, COALESCING_TIMESET_TIMESET, timeset);
SET_FIELD(p_coal_timeset->value, COALESCING_TIMESET_VALID, 1);
qed_memcpy_to(p_hwfn, p_ptt, hw_addr, p_eth_qzone, eth_qzone_size);
@@ -3702,12 +3702,46 @@ static int qed_set_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
return 0;
}
-int qed_set_rxq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
- u16 coalesce, u16 qid, u16 sb_id)
+int qed_set_queue_coalesce(u16 rx_coal, u16 tx_coal, void *p_handle)
+{
+ struct qed_queue_cid *p_cid = p_handle;
+ struct qed_hwfn *p_hwfn;
+ struct qed_ptt *p_ptt;
+ int rc = 0;
+
+ p_hwfn = p_cid->p_owner;
+
+ if (IS_VF(p_hwfn->cdev))
+ return qed_vf_pf_set_coalesce(p_hwfn, rx_coal, tx_coal, p_cid);
+
+ p_ptt = qed_ptt_acquire(p_hwfn);
+ if (!p_ptt)
+ return -EAGAIN;
+
+ if (rx_coal) {
+ rc = qed_set_rxq_coalesce(p_hwfn, p_ptt, rx_coal, p_cid);
+ if (rc)
+ goto out;
+ p_hwfn->cdev->rx_coalesce_usecs = rx_coal;
+ }
+
+ if (tx_coal) {
+ rc = qed_set_txq_coalesce(p_hwfn, p_ptt, tx_coal, p_cid);
+ if (rc)
+ goto out;
+ p_hwfn->cdev->tx_coalesce_usecs = tx_coal;
+ }
+out:
+ qed_ptt_release(p_hwfn, p_ptt);
+ return rc;
+}
+
+int qed_set_rxq_coalesce(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ u16 coalesce, struct qed_queue_cid *p_cid)
{
struct ustorm_eth_queue_zone eth_qzone;
u8 timeset, timer_res;
- u16 fw_qid = 0;
u32 address;
int rc;
@@ -3724,32 +3758,29 @@ int qed_set_rxq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
}
timeset = (u8)(coalesce >> timer_res);
- rc = qed_fw_l2_queue(p_hwfn, qid, &fw_qid);
- if (rc)
- return rc;
-
- rc = qed_int_set_timer_res(p_hwfn, p_ptt, timer_res, sb_id, false);
+ rc = qed_int_set_timer_res(p_hwfn, p_ptt, timer_res,
+ p_cid->sb_igu_id, false);
if (rc)
goto out;
- address = BAR0_MAP_REG_USDM_RAM + USTORM_ETH_QUEUE_ZONE_OFFSET(fw_qid);
+ address = BAR0_MAP_REG_USDM_RAM +
+ USTORM_ETH_QUEUE_ZONE_OFFSET(p_cid->abs.queue_id);
rc = qed_set_coalesce(p_hwfn, p_ptt, address, ð_qzone,
sizeof(struct ustorm_eth_queue_zone), timeset);
if (rc)
goto out;
- p_hwfn->cdev->rx_coalesce_usecs = coalesce;
out:
return rc;
}
-int qed_set_txq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
- u16 coalesce, u16 qid, u16 sb_id)
+int qed_set_txq_coalesce(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ u16 coalesce, struct qed_queue_cid *p_cid)
{
struct xstorm_eth_queue_zone eth_qzone;
u8 timeset, timer_res;
- u16 fw_qid = 0;
u32 address;
int rc;
@@ -3766,22 +3797,16 @@ int qed_set_txq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
}
timeset = (u8)(coalesce >> timer_res);
- rc = qed_fw_l2_queue(p_hwfn, qid, &fw_qid);
- if (rc)
- return rc;
-
- rc = qed_int_set_timer_res(p_hwfn, p_ptt, timer_res, sb_id, true);
+ rc = qed_int_set_timer_res(p_hwfn, p_ptt, timer_res,
+ p_cid->sb_igu_id, true);
if (rc)
goto out;
- address = BAR0_MAP_REG_XSDM_RAM + XSTORM_ETH_QUEUE_ZONE_OFFSET(fw_qid);
+ address = BAR0_MAP_REG_XSDM_RAM +
+ XSTORM_ETH_QUEUE_ZONE_OFFSET(p_cid->abs.queue_id);
rc = qed_set_coalesce(p_hwfn, p_ptt, address, ð_qzone,
sizeof(struct xstorm_eth_queue_zone), timeset);
- if (rc)
- goto out;
-
- p_hwfn->cdev->tx_coalesce_usecs = coalesce;
out:
return rc;
}
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev_api.h b/drivers/net/ethernet/qlogic/qed/qed_dev_api.h
index 1f1df1b..e6b3c83 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev_api.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev_api.h
@@ -443,38 +443,23 @@ int qed_final_cleanup(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt, u16 id, bool is_vf);
/**
- * @brief qed_set_rxq_coalesce - Configure coalesce parameters for an Rx queue
- * The fact that we can configure coalescing to up to 511, but on varying
- * accuracy [the bigger the value the less accurate] up to a mistake of 3usec
- * for the highest values.
- *
- * @param p_hwfn
- * @param p_ptt
- * @param coalesce - Coalesce value in micro seconds.
- * @param qid - Queue index.
- * @param qid - SB Id
- *
- * @return int
- */
-int qed_set_rxq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
- u16 coalesce, u16 qid, u16 sb_id);
-
-/**
- * @brief qed_set_txq_coalesce - Configure coalesce parameters for a Tx queue
- * While the API allows setting coalescing per-qid, all tx queues sharing a
- * SB should be in same range [i.e., either 0-0x7f, 0x80-0xff or 0x100-0x1ff]
+ * @brief qed_set_queue_coalesce - Configure coalesce parameters for Rx or
+ * Tx queue. We can configure coalescing to up to 511, but on
+ * varying accuracy [the bigger the value the less accurate] up to a mistake
+ * of 3usec for the highest values.
+ * While the API allows setting coalescing per-qid, all queues sharing a SB
+ * should be in same range [i.e., either 0-0x7f, 0x80-0xff or 0x100-0x1ff]
* otherwise configuration would break.
*
- * @param p_hwfn
- * @param p_ptt
- * @param coalesce - Coalesce value in micro seconds.
- * @param qid - Queue index.
- * @param qid - SB Id
+ * @param rx_coal - Rx Coalesce value in micro seconds.
+ * @param tx_coal - TX Coalesce value in micro seconds.
+ * @param p_handle
*
* @return int
- */
-int qed_set_txq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
- u16 coalesce, u16 qid, u16 sb_id);
+ **/
+int
+qed_set_queue_coalesce(u16 rx_coal, u16 tx_coal, void *p_handle);
+
const char *qed_hw_get_resc_name(enum qed_resources res_id);
#endif
diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.h b/drivers/net/ethernet/qlogic/qed/qed_l2.h
index f8f09aa..60ea72c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.h
@@ -400,4 +400,11 @@ struct qed_queue_cid *
u8 qed_mcast_bin_from_mac(u8 *mac);
+int qed_set_rxq_coalesce(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ u16 coalesce, struct qed_queue_cid *p_cid);
+
+int qed_set_txq_coalesce(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ u16 coalesce, struct qed_queue_cid *p_cid);
#endif /* _QED_L2_H */
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 0a06683..448810a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1575,29 +1575,9 @@ static void qed_get_coalesce(struct qed_dev *cdev, u16 *rx_coal, u16 *tx_coal)
}
static int qed_set_coalesce(struct qed_dev *cdev, u16 rx_coal, u16 tx_coal,
- u16 qid, u16 sb_id)
+ void *handle)
{
- struct qed_hwfn *hwfn;
- struct qed_ptt *ptt;
- int hwfn_index;
- int status = 0;
-
- hwfn_index = qid % cdev->num_hwfns;
- hwfn = &cdev->hwfns[hwfn_index];
- ptt = qed_ptt_acquire(hwfn);
- if (!ptt)
- return -EAGAIN;
-
- status = qed_set_rxq_coalesce(hwfn, ptt, rx_coal,
- qid / cdev->num_hwfns, sb_id);
- if (status)
- goto out;
- status = qed_set_txq_coalesce(hwfn, ptt, tx_coal,
- qid / cdev->num_hwfns, sb_id);
-out:
- qed_ptt_release(hwfn, ptt);
-
- return status;
+ return qed_set_queue_coalesce(rx_coal, tx_coal, handle);
}
static int qed_set_led(struct qed_dev *cdev, enum qed_led_mode mode)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index 2cfd3bd..5feef78 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -3400,6 +3400,86 @@ static void qed_iov_vf_mbx_release(struct qed_hwfn *p_hwfn,
length, status);
}
+static void qed_iov_vf_pf_set_coalesce(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ struct qed_vf_info *vf)
+{
+ struct qed_iov_vf_mbx *mbx = &vf->vf_mbx;
+ struct vfpf_update_coalesce *req;
+ u8 status = PFVF_STATUS_FAILURE;
+ struct qed_queue_cid *p_cid;
+ u16 rx_coal, tx_coal;
+ int rc = 0, i;
+ u16 qid;
+
+ req = &mbx->req_virt->update_coalesce;
+
+ rx_coal = req->rx_coal;
+ tx_coal = req->tx_coal;
+ qid = req->qid;
+
+ if (!qed_iov_validate_rxq(p_hwfn, vf, qid,
+ QED_IOV_VALIDATE_Q_ENABLE) && rx_coal) {
+ DP_VERBOSE(p_hwfn, QED_MSG_IOV,
+ "VF[%d]: Invalid Rx queue_id = %d\n",
+ vf->abs_vf_id, qid);
+ goto out;
+ }
+
+ if (!qed_iov_validate_txq(p_hwfn, vf, qid,
+ QED_IOV_VALIDATE_Q_ENABLE) && tx_coal) {
+ DP_VERBOSE(p_hwfn, QED_MSG_IOV,
+ "VF[%d]: Invalid Tx queue_id = %d\n",
+ vf->abs_vf_id, qid);
+ goto out;
+ }
+
+ DP_VERBOSE(p_hwfn,
+ QED_MSG_IOV,
+ "VF[%d]: Setting coalesce for VF rx_coal = %d, tx_coal = %d at queue = %d\n",
+ vf->abs_vf_id, rx_coal, tx_coal, qid);
+
+ if (rx_coal) {
+ p_cid = qed_iov_get_vf_rx_queue_cid(&vf->vf_queues[qid]);
+
+ rc = qed_set_rxq_coalesce(p_hwfn, p_ptt, rx_coal, p_cid);
+ if (rc) {
+ DP_VERBOSE(p_hwfn,
+ QED_MSG_IOV,
+ "VF[%d]: Unable to set rx queue = %d coalesce\n",
+ vf->abs_vf_id, vf->vf_queues[qid].fw_rx_qid);
+ goto out;
+ }
+ }
+
+ if (tx_coal) {
+ struct qed_vf_queue *p_queue = &vf->vf_queues[qid];
+
+ for (i = 0; i < MAX_QUEUES_PER_QZONE; i++) {
+ if (!p_queue->cids[i].p_cid)
+ continue;
+
+ if (!p_queue->cids[i].b_is_tx)
+ continue;
+
+ rc = qed_set_txq_coalesce(p_hwfn, p_ptt, tx_coal,
+ p_queue->cids[i].p_cid);
+
+ if (rc) {
+ DP_VERBOSE(p_hwfn,
+ QED_MSG_IOV,
+ "VF[%d]: Unable to set tx queue coalesce\n",
+ vf->abs_vf_id);
+ goto out;
+ }
+ }
+ }
+
+ status = PFVF_STATUS_SUCCESS;
+out:
+ qed_iov_prepare_resp(p_hwfn, p_ptt, vf, CHANNEL_TLV_COALESCE_UPDATE,
+ sizeof(struct pfvf_def_resp_tlv), status);
+}
static int
qed_iov_vf_flr_poll_dorq(struct qed_hwfn *p_hwfn,
struct qed_vf_info *p_vf, struct qed_ptt *p_ptt)
@@ -3725,6 +3805,9 @@ static void qed_iov_process_mbx_req(struct qed_hwfn *p_hwfn,
case CHANNEL_TLV_UPDATE_TUNN_PARAM:
qed_iov_vf_mbx_update_tunn_param(p_hwfn, p_ptt, p_vf);
break;
+ case CHANNEL_TLV_COALESCE_UPDATE:
+ qed_iov_vf_pf_set_coalesce(p_hwfn, p_ptt, p_vf);
+ break;
}
} else if (qed_iov_tlv_supported(mbx->first_tlv.tl.type)) {
DP_VERBOSE(p_hwfn, QED_MSG_IOV,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.c b/drivers/net/ethernet/qlogic/qed/qed_vf.c
index 1926d1e..0a7bbc0 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.c
@@ -1343,6 +1343,50 @@ int qed_vf_pf_int_cleanup(struct qed_hwfn *p_hwfn)
return rc;
}
+int
+qed_vf_pf_set_coalesce(struct qed_hwfn *p_hwfn,
+ u16 rx_coal, u16 tx_coal, struct qed_queue_cid *p_cid)
+{
+ struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
+ struct vfpf_update_coalesce *req;
+ struct pfvf_def_resp_tlv *resp;
+ int rc;
+
+ /* clear mailbox and prep header tlv */
+ req = qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_COALESCE_UPDATE, sizeof(*req));
+
+ req->rx_coal = rx_coal;
+ req->tx_coal = tx_coal;
+ req->qid = p_cid->rel.queue_id;
+
+ DP_VERBOSE(p_hwfn,
+ QED_MSG_IOV,
+ "Setting coalesce rx_coal = %d, tx_coal = %d at queue = %d\n",
+ rx_coal, tx_coal, req->qid);
+
+ /* add list termination tlv */
+ qed_add_tlv(p_hwfn, &p_iov->offset, CHANNEL_TLV_LIST_END,
+ sizeof(struct channel_list_end_tlv));
+
+ resp = &p_iov->pf2vf_reply->default_resp;
+ rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, sizeof(*resp));
+ if (rc)
+ goto exit;
+
+ if (resp->hdr.status != PFVF_STATUS_SUCCESS)
+ goto exit;
+
+ if (rx_coal)
+ p_hwfn->cdev->rx_coalesce_usecs = rx_coal;
+
+ if (tx_coal)
+ p_hwfn->cdev->tx_coalesce_usecs = tx_coal;
+
+exit:
+ qed_vf_pf_req_end(p_hwfn, rc);
+ return rc;
+}
+
u16 qed_vf_get_igu_sb_id(struct qed_hwfn *p_hwfn, u16 sb_id)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.h b/drivers/net/ethernet/qlogic/qed/qed_vf.h
index 34d9b88..2d9fdd6 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.h
@@ -497,6 +497,13 @@ struct tlv_buffer_size {
u8 tlv_buffer[TLV_BUFFER_SIZE];
};
+struct vfpf_update_coalesce {
+ struct vfpf_first_tlv first_tlv;
+ u16 rx_coal;
+ u16 tx_coal;
+ u16 qid;
+ u8 padding[2];
+};
union vfpf_tlvs {
struct vfpf_first_tlv first_tlv;
struct vfpf_acquire_tlv acquire;
@@ -509,6 +516,7 @@ struct tlv_buffer_size {
struct vfpf_vport_update_tlv vport_update;
struct vfpf_ucast_filter_tlv ucast_filter;
struct vfpf_update_tunn_param_tlv tunn_param_update;
+ struct vfpf_update_coalesce update_coalesce;
struct channel_list_end_tlv list_end;
struct tlv_buffer_size tlv_buf_size;
};
@@ -624,7 +632,7 @@ enum {
CHANNEL_TLV_VPORT_UPDATE_ACCEPT_ANY_VLAN,
CHANNEL_TLV_VPORT_UPDATE_SGE_TPA,
CHANNEL_TLV_UPDATE_TUNN_PARAM,
- CHANNEL_TLV_RESERVED,
+ CHANNEL_TLV_COALESCE_UPDATE,
CHANNEL_TLV_QID,
CHANNEL_TLV_MAX,
@@ -677,6 +685,20 @@ struct qed_vf_iov {
bool b_doorbell_bar;
};
+/**
+ * @brief VF - Set Rx/Tx coalesce per VF's relative queue.
+ * Coalesce value '0' will omit the configuration.
+ *
+ * @param p_hwfn
+ * @param rx_coal - coalesce value in micro second for rx queue
+ * @param tx_coal - coalesce value in micro second for tx queue
+ * @param p_cid - queue cid
+ *
+ **/
+int qed_vf_pf_set_coalesce(struct qed_hwfn *p_hwfn,
+ u16 rx_coal,
+ u16 tx_coal, struct qed_queue_cid *p_cid);
+
#ifdef CONFIG_QED_SRIOV
/**
* @brief Read the VF bulletin and act on it if needed
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index 55fa2ef..76e0b13 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -718,8 +718,9 @@ static int qede_set_coalesce(struct net_device *dev,
struct ethtool_coalesce *coal)
{
struct qede_dev *edev = netdev_priv(dev);
+ struct qede_fastpath *fp;
int i, rc = 0;
- u16 rxc, txc, sb_id;
+ u16 rxc, txc;
if (!netif_running(dev)) {
DP_INFO(edev, "Interface is down\n");
@@ -730,21 +731,36 @@ static int qede_set_coalesce(struct net_device *dev,
coal->tx_coalesce_usecs > QED_COALESCE_MAX) {
DP_INFO(edev,
"Can't support requested %s coalesce value [max supported value %d]\n",
- coal->rx_coalesce_usecs > QED_COALESCE_MAX ? "rx"
- : "tx",
- QED_COALESCE_MAX);
+ coal->rx_coalesce_usecs > QED_COALESCE_MAX ? "rx" :
+ "tx", QED_COALESCE_MAX);
return -EINVAL;
}
rxc = (u16)coal->rx_coalesce_usecs;
txc = (u16)coal->tx_coalesce_usecs;
for_each_queue(i) {
- sb_id = edev->fp_array[i].sb_info->igu_sb_id;
- rc = edev->ops->common->set_coalesce(edev->cdev, rxc, txc,
- (u16)i, sb_id);
- if (rc) {
- DP_INFO(edev, "Set coalesce error, rc = %d\n", rc);
- return rc;
+ fp = &edev->fp_array[i];
+
+ if (edev->fp_array[i].type & QEDE_FASTPATH_RX) {
+ rc = edev->ops->common->set_coalesce(edev->cdev,
+ rxc, 0,
+ fp->rxq->handle);
+ if (rc) {
+ DP_INFO(edev,
+ "Set RX coalesce error, rc = %d\n", rc);
+ return rc;
+ }
+ }
+
+ if (edev->fp_array[i].type & QEDE_FASTPATH_TX) {
+ rc = edev->ops->common->set_coalesce(edev->cdev,
+ 0, txc,
+ fp->txq->handle);
+ if (rc) {
+ DP_INFO(edev,
+ "Set TX coalesce error, rc = %d\n", rc);
+ return rc;
+ }
}
}
@@ -1758,6 +1774,8 @@ static int qede_set_eee(struct net_device *dev, struct ethtool_eee *edata)
.get_msglevel = qede_get_msglevel,
.set_msglevel = qede_set_msglevel,
.get_link = qede_get_link,
+ .get_coalesce = qede_get_coalesce,
+ .set_coalesce = qede_set_coalesce,
.get_ringparam = qede_get_ringparam,
.set_ringparam = qede_set_ringparam,
.get_strings = qede_get_strings,
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index 9f32762..4d59ca1 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -694,8 +694,8 @@ struct qed_common_ops {
*
* @return 0 on success, error otherwise.
*/
- int (*set_coalesce)(struct qed_dev *cdev, u16 rx_coal, u16 tx_coal,
- u16 qid, u16 sb_id);
+ int (*set_coalesce)(struct qed_dev *cdev,
+ u16 rx_coal, u16 tx_coal, void *handle);
/**
* @brief set_led - Configure LED mode
--
1.7.1
^ permalink raw reply related
* [PATCH v2 net-next 7/7] qed: enhanced per queue max coalesce value.
From: Manish Chopra @ 2017-07-26 13:07 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz, rahul.verma, sudarsana.kalluru
In-Reply-To: <20170726130715.12976-1-manish.chopra@cavium.com>
From: Rahul Verma <rahul.verma@cavium.com>
Maximum coalesce per Rx/Tx queue is extended from
255 to 511.
Signed-off-by: Rahul Verma <rahul.verma@cavium.com>
Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
---
include/linux/qed/qed_if.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index 2b4720b..cc646ca 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -184,7 +184,7 @@ enum qed_led_mode {
#define DIRECT_REG_RD(reg_addr) readl((void __iomem *)(reg_addr))
-#define QED_COALESCE_MAX 0xFF
+#define QED_COALESCE_MAX 0x1FF
#define QED_DEFAULT_RX_USECS 12
#define QED_DEFAULT_TX_USECS 48
--
1.7.1
^ permalink raw reply related
* [PATCH v2 net-next 4/7] qede: Add ethtool support for Energy efficient ethernet.
From: Manish Chopra @ 2017-07-26 13:07 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz, rahul.verma, sudarsana.kalluru
In-Reply-To: <20170726130715.12976-1-manish.chopra@cavium.com>
From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
The patch adds ethtool callback implementations for querying/configuring
the Energy Efficient Ethernet (EEE) parameters.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 84 +++++++++++++++++++++++
1 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index e31266d..55fa2ef 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -1631,6 +1631,87 @@ static int qede_get_tunable(struct net_device *dev,
return 0;
}
+static int qede_get_eee(struct net_device *dev, struct ethtool_eee *edata)
+{
+ struct qede_dev *edev = netdev_priv(dev);
+ struct qed_link_output current_link;
+
+ memset(¤t_link, 0, sizeof(current_link));
+ edev->ops->common->get_link(edev->cdev, ¤t_link);
+
+ if (!current_link.eee_supported) {
+ DP_INFO(edev, "EEE is not supported\n");
+ return -EOPNOTSUPP;
+ }
+
+ if (current_link.eee.adv_caps & QED_EEE_1G_ADV)
+ edata->advertised = ADVERTISED_1000baseT_Full;
+ if (current_link.eee.adv_caps & QED_EEE_10G_ADV)
+ edata->advertised |= ADVERTISED_10000baseT_Full;
+ if (current_link.sup_caps & QED_EEE_1G_ADV)
+ edata->supported = ADVERTISED_1000baseT_Full;
+ if (current_link.sup_caps & QED_EEE_10G_ADV)
+ edata->supported |= ADVERTISED_10000baseT_Full;
+ if (current_link.eee.lp_adv_caps & QED_EEE_1G_ADV)
+ edata->lp_advertised = ADVERTISED_1000baseT_Full;
+ if (current_link.eee.lp_adv_caps & QED_EEE_10G_ADV)
+ edata->lp_advertised |= ADVERTISED_10000baseT_Full;
+
+ edata->tx_lpi_timer = current_link.eee.tx_lpi_timer;
+ edata->eee_enabled = current_link.eee.enable;
+ edata->tx_lpi_enabled = current_link.eee.tx_lpi_enable;
+ edata->eee_active = current_link.eee_active;
+
+ return 0;
+}
+
+static int qede_set_eee(struct net_device *dev, struct ethtool_eee *edata)
+{
+ struct qede_dev *edev = netdev_priv(dev);
+ struct qed_link_output current_link;
+ struct qed_link_params params;
+
+ if (!edev->ops->common->can_link_change(edev->cdev)) {
+ DP_INFO(edev, "Link settings are not allowed to be changed\n");
+ return -EOPNOTSUPP;
+ }
+
+ memset(¤t_link, 0, sizeof(current_link));
+ edev->ops->common->get_link(edev->cdev, ¤t_link);
+
+ if (!current_link.eee_supported) {
+ DP_INFO(edev, "EEE is not supported\n");
+ return -EOPNOTSUPP;
+ }
+
+ memset(¶ms, 0, sizeof(params));
+ params.override_flags |= QED_LINK_OVERRIDE_EEE_CONFIG;
+
+ if (!(edata->advertised & (ADVERTISED_1000baseT_Full |
+ ADVERTISED_10000baseT_Full)) ||
+ ((edata->advertised & (ADVERTISED_1000baseT_Full |
+ ADVERTISED_10000baseT_Full)) !=
+ edata->advertised)) {
+ DP_VERBOSE(edev, QED_MSG_DEBUG,
+ "Invalid advertised capabilities %d\n",
+ edata->advertised);
+ return -EINVAL;
+ }
+
+ if (edata->advertised & ADVERTISED_1000baseT_Full)
+ params.eee.adv_caps = QED_EEE_1G_ADV;
+ if (edata->advertised & ADVERTISED_10000baseT_Full)
+ params.eee.adv_caps |= QED_EEE_10G_ADV;
+ params.eee.enable = edata->eee_enabled;
+ params.eee.tx_lpi_enable = edata->tx_lpi_enabled;
+ params.eee.tx_lpi_timer = edata->tx_lpi_timer;
+
+ params.link_up = true;
+ edev->ops->common->set_link(edev->cdev, ¶ms);
+
+ return 0;
+}
+
static const struct ethtool_ops qede_ethtool_ops = {
.get_link_ksettings = qede_get_link_ksettings,
.set_link_ksettings = qede_set_link_ksettings,
@@ -1664,6 +1745,9 @@ static int qede_get_tunable(struct net_device *dev,
.get_channels = qede_get_channels,
.set_channels = qede_set_channels,
.self_test = qede_self_test,
+ .get_eee = qede_get_eee,
+ .set_eee = qede_set_eee,
+
.get_tunable = qede_get_tunable,
.set_tunable = qede_set_tunable,
};
--
1.7.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