- 14 Apr, 2015 35 commits
-
-
Jeff Kirsher authored
Add a header comment explaining why we have the somewhat crazy mailbox flow. This flow is necessary as it prevents the PF<->SM mailbox from being flooded by the VF messages, which normally trigger a message to the PF. This helps prevent the case where we see a PF mailbox timeout. Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Acked-by:
Matthew Vick <matthew.vick@intel.com> Tested-by:
Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by:
-
Jeff Kirsher authored
Since we already schedule the service task, we can just wait for this task to handle the mailbox events from the VF. This reduces some complex code flow, and makes it so we have a single path for handling the VF messages. There is a possibility that we have a slight delay in handling VF messages, but it should be minimal. The result of tx_complete and !rx_ready is insufficient to determine whether we need to process the mailbox. There is a possible race condition whereby the VF fills up the mbmem for us, but we have already recently processed the mailboxes in the interrupt. During this time, the interrupt is disabled. Thus, our Rx FIFO is empty, but the mbmem now has data in it. Since we continually check whether Rx FIFO is empty, we then never call process. This results in the possibility to prevent PF from handling the VF mailbox messages. Instead, just call process every time, despite the fact that we may or may not have anything to process for the VF. There should be minimal overhead for doing this, and it resolves an issue where the VF never comes up due to never getting response for its SET_LPORT_STATE message. Signed-off-by:
-
Jeff Kirsher authored
Since we run the watchdog periodically, which might take a while and potentially monopolize the system default workqueue, create our own separate work queue. This also helps reduce and stabilize latency between scheduling the work in our interrupt and actually performing the work. Still use a timer for the regular scheduled interval but queue the work onto its own work queue. It seemed overkill to create a single workqueue per interface, so we just spawn a single work queue for all interfaces upon driver load. For this reason, use a multi-threaded workqueue with one thread per processor, rather than single threaded queue. Signed-off-by:
-
Jeff Kirsher authored
When returning virtualization queues from the VF back to the PF, do not retain the VF rate limiter. Signed-off-by:
Todd Russell <todd.a.russell@intel.com> Acked-by:
-
Jeff Kirsher authored
Named it tx_hang_count to differentiate it from tx_hwtstamp_timeout. Signed-off-by:
-
Jeff Kirsher authored
We were incrementing the tx_timeout_count for both the Tx hang and then for all reset flows. Instead, we should only increment tx_timeout_count in the Tx hang path, so that our Tx hang counter does not increment when it was not caused by a Tx hang. Signed-off-by:
-
Jeff Kirsher authored
Since we already print this message when a reset is requested via the RESET_REQUESTED flag, we do not need to print it before setting the flag. Signed-off-by:
-
Jeff Kirsher authored
This patch resolves an issue with ethtool stats displaying useless values on the VF, because some stats simply have no meaning to the VF. Resolve this by splitting these out into PF_STATS and only showing them if we aren't the VF. Signed-off-by:
-
Jeff Kirsher authored
Even though it shouldn't strictly matter, don't count queue stats higher than the max_queues value stored for this mac. This ensures that we don't attempt to check queues which don't belong to use in VFs. This shouldn't be a visible change, as the VFs should see zero for queues which don't belong to them. Signed-off-by:
-
Jeff Kirsher authored
Currently, we show statistics for all 128 queues, even though we don't necessarily have that many queues available especially in the VF case. Instead, use the hw->mac.max_queues value, which tells us how many queues we actually have, rather than the space for the rings we allocated. In this way, we prevent dumping statistics that are useless on the VF. Signed-off-by:
-
Jeff Kirsher authored
Previously, the user was not allowed to create a VLAN interface on top of the switch default vid. Signed-off-by:
-
Jeff Kirsher authored
The were several functions which had parameters which were never or sometimes used in functions. To resolve possible compiler warnings, use __always_unused or __maybe_unused kernel macros to resolve. Signed-off-by:
-
Jeff Kirsher authored
This change adds a function called "fm10k_netpoll" that's used to define "ndo_poll_controller" in "fm10k_netdev_ops". This is required to enable support for "netconsole" in fm10k. Signed-off-by:
Ngai-Mint Kwan <ngai-mint.kwan@intel.com> Acked-by:
-
Jeff Kirsher authored
Currently, the VFs do not read the default VLAN during initialization, so they will not be able to indicate untagged frames properly. Signed-off-by:
-
Jeff Kirsher authored
Corrected a spelling mistake that was found over time. Signed-off-by:
-
Jeff Kirsher authored
Output of ethtool was reporting 2 rx_errors entries. This change removes one of the redundant entries. Signed-off-by:
-
Jeff Kirsher authored
The function collecting Tx statistics was actually using values from the RX ring. Thus, Tx and Rx statistics values reported by "ifconfig" will return identical values. This change corrects this error and the Tx statistics is now reading from the Tx ring. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
The dwmac-socfpga.c conflict was a case of a bug fix overlapping changes in net-next to handle an error pointer differently. Signed-off-by:David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Hariprasad Shenai says: ==================== cxgb4: Misc. fixes for sge Increases value of MAX_IMM_TX_PKT_LEN to improve latency, fill freelist starving threshold based on adapter type, add comments for tx flits and sge length code and don't call t4_slow_intr_handler when we are not master PF. This patch series has been created against net-next tree and includes patches on cxgb4 driver We have included all the maintainers of respective drivers. Kindly review the change and let us know in case of any review comments. ==================== Signed-off-by: -
Hariprasad Shenai authored
Signed-off-by:
Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by:
-
Hariprasad Shenai authored
Add comment for tx filt and sge length calucaltion code, also remove a hardcoded value Signed-off-by:
-
Hariprasad Shenai authored
Signed-off-by:
-
Hariprasad Shenai authored
fl_starv_thres could be different from adapter to adapter, don't use hardcoded values Signed-off-by:
-
Hariprasad Shenai authored
This allows a significant latency drop for packets of sizes between 128 and 192 bytes Signed-off-by:
-
Felix Fietkau authored
The ring size is always known at compile time, so make the code a bit more efficient Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
The driver needs to inform the hardware about the first invalid (not yet filled) rx slot, by writing its DMA descriptor pointer offset to the BGMAC_DMA_RX_INDEX register. This register was set to a value exceeding the rx ring size, effectively allowing the hardware constant access to the full ring, regardless of which slots are initialized. To fix this issue, always mark the last filled rx slot as invalid. Signed-off-by:
-
Felix Fietkau authored
Instead of allocating buffers at device init time and initializing descriptors at device open, do both at the same time (during open). Free all buffers when closing the device. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Felix Fietkau authored
Limiting it to 511 looks like a failed attempt at leaving one descriptor empty to allow the hardware to stop processing a buffer that has not been prepared yet. However, this doesn't work because this affects the total ring size as well Signed-off-by:
-
Felix Fietkau authored
In very rare cases, the MAC can catch an internal buffer that is bigger than it's supposed to be. Instead of crashing the kernel, simply pass the buffer back to the hardware Signed-off-by:
-
Felix Fietkau authored
Allocate a new buffer before processing the completed one. If allocation fails, reuse the old buffer. Signed-off-by:
-
Felix Fietkau authored
A packet buffer offset of 30 bytes is inefficient, because the first 2 bytes end up in a different cacheline. Signed-off-by:
-
Felix Fietkau authored
Always poll rx and tx during NAPI poll instead of relying on the status of the first interrupt. This prevents bgmac_poll from leaving unfinished work around until the next IRQ. In my tests this makes bridging/routing throughput under heavy load more stable and ensures that no new IRQs arrive as long as bgmac_poll uses up the entire budget. Signed-off-by:
-
Felix Fietkau authored
Keep incrementing ring->start and ring->end instead of pointing it to the actual ring slot entry. This simplifies the calculation of the number of free slots. Signed-off-by:
-
Daniel Axtens authored
The toshiba drivers had celleb as an optional dependency. celleb has been dropped [1], so clean that out of Kconfig. [1] http://patchwork.ozlabs.org/patch/451730/ CC: netdev@vger.kernel.org CC: Valentin Rothberg <valentinrothberg@gmail.com> CC: mpe@ellerman.id.au CC: linuxppc-dev@lists.ozlabs.org Signed-off-by:
Daniel Axtens <dja@axtens.net> Signed-off-by:
-
Haiyang Zhang authored
If remaining space in a send buffer slot is too small for the whole message, we only copy the RNDIS header and PPI data into send buffer, so we can batch one more packet each time. It reduces the vmbus per-message overhead. Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
- 13 Apr, 2015 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsDavid S. Miller authored
Al Viro says: ==================== netdev-related stuff in vfs.git There are several commits sitting in vfs.git that probably ought to go in via net-next.git. First of all, there's merge with vfs.git#iocb - that's Christoph's aio rework, which has triggered conflicts with the ->sendmsg() and ->recvmsg() patches a while ago. It's not so much Christoph's stuff that ought to be in net-next, as (pretty simple) conflict resolution on merge. The next chunk is switch to {compat_,}import_iovec/import_single_range - new safer primitives for initializing iov_iter. The primitives themselves come from vfs/git#iov_iter (and they are used quite a lot in vfs part of queue), conversion of net/socket.c syscalls belongs in net-next, IMO. Next there's afs and rxrpc stuff from dhowells. And then there's sanitizing kernel_sendmsg et.al. + missing inlined helper for "how much data is left in msg->msg_iter" - this stuff is used in e.g. cifs stuff, but it belongs in net-next. That pile is pullable from git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-davem I'll post the individual patches in there in followups; could you take a look and tell if everything in there is OK with you? ==================== Signed-off-by: -
Eric Dumazet authored
Using a timer wheel for timewait sockets was nice ~15 years ago when memory was expensive and machines had a single processor. This does not scale, code is ugly and source of huge latencies (Typically 30 ms have been seen, cpus spinning on death_lock spinlock.) We can afford to use an extra 64 bytes per timewait sock and spread timewait load to all cpus to have better behavior. Tested: On following test, /proc/sys/net/ipv4/tcp_tw_recycle is set to 1 on the target (lpaa24) Before patch : lpaa23:~# ./super_netperf 200 -H lpaa24 -t TCP_CC -l 60 -- -p0,0 419594 lpaa23:~# ./super_netperf 200 -H lpaa24 -t TCP_CC -l 60 -- -p0,0 437171 While test is running, we can observe 25 or even 33 ms latencies. lpaa24:~# ping -c 1000 -i 0.02 -qn lpaa23 ... 1000 packets transmitted, 1000 received, 0% packet loss, time 20601ms rtt min/avg/max/mdev = 0.020/0.217/25.771/1.535 ms, pipe 2 lpaa24:~# ping -c 1000 -i 0.02 -qn lpaa23 ... 1000 packets transmitted, 1000 received, 0% packet loss, time 20702ms rtt min/avg/max/mdev = 0.019/0.183/33.761/1.441 ms, pipe 2 After patch : About 90% increase of throughput : lpaa23:~# ./super_netperf 200 -H lpaa24 -t TCP_CC -l 60 -- -p0,0 810442 lpaa23:~# ./super_netperf 200 -H lpaa24 -t TCP_CC -l 60 -- -p0,0 800992 And latencies are kept to minimal values during this load, even if network utilization is 90% higher : lpaa24:~# ping -c 1000 -i 0.02 -qn lpaa23 ... 1000 packets transmitted, 1000 received, 0% packet loss, time 19991ms rtt min/avg/max/mdev = 0.023/0.064/0.360/0.042 ms Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Richard Weinberger authored
The printed values are all of type unsigned integer, therefore use %u instead of %d. Otherwise an user can face negative values. Signed-off-by:
Richard Weinberger <richard@nod.at> Acked-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Richard Weinberger authored
The printed values are all of type unsigned integer, therefore use %u instead of %d. Otherwise an user can face negative values. Fixes: $ cat /proc/net/netfilter/nfnetlink_queue 0 29508 278 2 65531 0 2004213241 -2129885586 1 1 -27747 0 2 65531 0 0 0 1 2 -27748 0 2 65531 0 0 0 1 Signed-off-by: -
Richard Weinberger authored
The netlink portid is an unsigned integer, use this type also in netfilter. Signed-off-by:
-
