Rather than passing all the contents of flush_tlb_info to
flush_tlb_others(), pass a pointer to the structure directly. For
consistency, this also removes the unnecessary cpu parameter from
uv_flush_tlb_others() to make its signature match the other
*flush_tlb_others() functions.
This serves two purposes:
- It will dramatically simplify future patches that change struct
flush_tlb_info, which I'm planning to do.
- struct flush_tlb_info is an adequate description of what to do
for a local flush, too, so by reusing it we can remove duplicated
code between local and remove flushes in a future patch.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bpetkov@suse.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: Nadav Amit <namit@vmware.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
[ Fix build warning. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
copy_from_gs() and copy_to_gs() are unused in the boot code. They have
actually never been used -- they were always commented out since their
addition in 2007:
5be8656615 ("String-handling functions for the new x86 setup code.")
So remove them -- they can be restored from history if needed.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170531081243.5709-1-jslaby@suse.cz
Signed-off-by: Ingo Molnar <mingo@kernel.org>
When the tick is stopped and we reach the dynticks evaluation code on
IRQ exit, we perform a soft tick restart if we observe an expired timer
from there. It means we program the nearest possible tick but we stay in
dynticks mode (ts->tick_stopped = 1) because we may need to stop the tick
again after that expired timer is handled.
Now this solution works most of the time but if we suffer an IRQ storm
and those interrupts trigger faster than the hardware clockevents min
delay, our tick won't fire until that IRQ storm is finished.
Here is the problem: on IRQ exit we reprog the timer to at least
NOW() + min_clockevents_delay. Another IRQ fires before the tick so we
reschedule again to NOW() + min_clockevents_delay, etc... The tick
is eternally rescheduled min_clockevents_delay ahead.
A solution is to simply remove this soft tick restart. After all
the normal dynticks evaluation path can handle 0 delay just fine. And
by doing that we benefit from the optimization branch which avoids
clock reprogramming if the clockevents deadline hasn't changed since
the last reprog. This fixes our issue because we don't do repetitive
clock reprog that always add hardware min delay.
As a side effect it should even optimize the 0 delay path in general.
Reported-and-tested-by: Octavian Purdila <octavian.purdila@nxp.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1496328429-13317-1-git-send-email-fweisbec@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
There is no more set_task_vxid() helper, remove its description.
Signed-off-by: Perr Zhang <strongbox8@zoho.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170602035953.28949-1-strongbox8@zoho.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This would prevent the liblockdep error messages from getting
mixed in with the test result output.
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Cc: ben@decadent.org.uk
Link: http://lkml.kernel.org/r/20170525130005.5947-22-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
- More rcu stubs
- New dummy headers due to sched header split
- jhash2 included in due to kernel lockdep inclusion and usage
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Cc: ben@decadent.org.uk
Link: http://lkml.kernel.org/r/20170525130005.5947-13-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Mixing fd-based and stream-base IO results in interleaved output like
following:
=====================================
liblockdep 4.7.6
-------------------------------------
conopal/372 is trying to release lock (0x3a45c) at:
/lib/libpt.so.2.17-alpha2(_ZN11PTimedMutex6SignalEv+0x3c) [0xb613c688]
but there are no more locks to release!
other info that might help us debug this:
no locks held by conopal/372.
stack backtrace:
=====================================
liblockdep 4.7.6
---------------------------------/usr/lib/liblockdep.so.4.7.6(+0x1e3c)[0xb67c2e3c]
/usr/lib/liblockdep.so.4.7.6(+0x5fe0)[0xb67c6fe0]
/usr/lib/liblockdep.so.4.7.6(+0x6450)[0xb67c7450]
/usr/lib/liblockdep.so.4.7.6(lock_release+0x5c)[0xb67c7c40]
/usr/lib/liblockdep.so.4.7.6(pthread_mutex_unlock+0x38)[0xb67c91d4]
/lib/libpt.so.2.17-alpha2(_ZN11PTimedMutex6SignalEv+0x3c)[0xb613c688]
/lib/libpt.so.2.17-alpha2(_ZN10PContainer14AssignContentsERKS_+0xe4)[0xb6160730]
/lib/libopal.so.3.17-alpha2(_ZN15OpalMediaFormat14AssignContentsERK10PContainer+0x90)[0xb6435edc]
/lib/libopal.so.3.17-alpha2(_ZN15OpalMediaFormataSERK7PString+0x68)[0xb643b610]
/lib/libopal.so.3.17-alpha2(_ZN15OpalMediaFormatC2EPKc+0x68)[0xb643b6cc]
/lib/libopal.so.3.17-alpha2(_ZN11OpalWAVFile14AddMediaFormatERK15OpalMediaFormat+0x330)[0xb66b2224]
/lib/libopal.so.3.17-alpha2(+0x2526f8)[0xb640c6f8]
/lib/ld-linux-armhf.so.3(+0x102f0)[0xb6f852f0]
/lib/ld-linux-armhf.so.3(+0x1044c)[0xb6f8544c]
/lib/ld-linux-armhf.so.3(+0xac4)[0xb6f75ac4]
/usr/lib/liblockdep.so.4.7.6(+0x1e3c)[0xb67c2e3c]
/usr/lib/liblockdep.so.4.7.6(+0x5fe0)[0xb67c6fe0]
/usr/lib/liblockdep.so.4.7.6(+0x6450)[0xb67c7450]
/usr/lib/liblockdep.so.4.7.6(lock_release+0x5c)[0xb67c7c40]
/usr/lib/liblockdep.so.4.7.6(pthread_mutex_unlock+0x38)[0xb67c91d4]
/lib/libpt.so.2.17-alpha2(_ZN11PTimedMutex6SignalEv+0x3c)[0xb613c688]
/lib/libopal.so.3.17-alpha2(_ZN15OpalMediaFormat14AssignContentsERK10PContainer+0x78)[0xb6435ec4]
/lib/libopal.so.3.17-alpha2(_ZN15OpalMediaFormataSERK7PString+0x68)[0xb643b610]
/lib/libopal.so.3.17-alpha2(_ZN15OpalMediaFormatC2EPKc+0x68)[0xb643b6cc]
/lib/libopal.so.3.17-alpha2(_ZN11OpalWAVFile14AddMediaFormatERK15OpalMediaFormat+0x330)[0xb66b2224]
/lib/libopal.so.3.17-alpha2(+0x2526f8)[0xb640c6f8]
/lib/ld-linux-armhf.so.3(+0x102f0)[0xb6f852f0]
/lib/ld-linux-armhf.so.3(+0x1044c)[0xb6f8544c]
/lib/ld-linux-armhf.so.3(+0xac4)[0xb6f75ac4]
Therefore change all bare printf(...) to dprintf(STDOUT_FILENO, ...) to
sychronize with backtrace_symbols_fd().
[ BUG: bad unlock balance detected! ]
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Cc: ben@decadent.org.uk
Link: http://lkml.kernel.org/r/20170525130005.5947-12-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
With -lpthread option, the test for ABBA_2threads was
failing, and test passed if it was removed.
Since -pthread compiler option is sufficient for linking
to pthread libraries, this patch removes -lpthread.
Signed-off-by: Vishal Thanki <vishalthanki@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Cc: ben@decadent.org.uk
Link: http://lkml.kernel.org/r/20170525130005.5947-9-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
We define init_utsname() as static but not inline, resulting
in a warning for every source file that includes lockdep.h but
doesn't call it.
Since it is only used by lockdep.c, define it in there.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Link: http://lkml.kernel.org/r/20170525130005.5947-8-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
liblockdep defines trivial macros for working with interrupt flags, as
interrupts are never disabled in userland. This results in warnings
from gcc when -Wunused-but-set-variable is enabled, and it is enabled
by -Wall. Fix this by evaluating the flags parameter and casting it to
void.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Link: http://lkml.kernel.org/r/20170525130005.5947-7-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
liblockdep defines various macros that may expand to an expression
with no effect, while the in-kernel definition does have an effect.
This results in warnings from gcc when -Wunused-value is enabled, and
is is enabled by -Wall. Fix this by introducing trivial functions,
as function return values are generally allowed to be ignored.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Link: http://lkml.kernel.org/r/20170525130005.5947-6-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Regressions in liblockdep may be missed because it doesn't enable
warnings.
Adding -Wall immediately introduces a lot of warnings, but those will
be fixed by the following commits.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Link: http://lkml.kernel.org/r/20170525130005.5947-5-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
liblockdep has been broken since commit 75dd602a51 ("lockdep: Fix
lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is
within the range of lock_chain::depth and in liblockdep it is much
too large.
That should have resulted in a compiler error, but didn't because:
- the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep
so is assumed to be an (undeclared) function
- putting a function call inside a BUILD_BUG_ON() expression quietly
turns it into some nonsense involving a variable-length array
It did produce a compiler warning, but I didn't notice because
liblockdep already produces too many warnings if -Wall is enabled
(which I'll fix shortly).
Even before that commit, which reduced lock_chain::depth from 8 bits
to 6, MAX_LOCK_DEPTH was too large.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: <stable@vger.kernel.org> # for versions before 4.6, use a value of 255
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Link: http://lkml.kernel.org/r/20170525130005.5947-3-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
__lock_pin_lock() now calls prandom_u32() which is not defined in
liblockdep. __lock_pin_lock() and its caller lock_pin_lock() are dead
code in liblockdep, but we still need to provide a definition of
prandom_u32() in case lazy binding is disabled.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Fixes: e7904a28f5 ("locking/lockdep, sched/core: Implement a better ...")
Link: http://lkml.kernel.org/r/20170525130005.5947-2-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
We want the tty locking fix in here, so that maybe we can finally get it
fixed for real...
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add myself as the maintainer for drivers/fsl/soc/ and fix the scope for
device tree bindings.
Signed-off-by: Li Yang <leoyang.li@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
This reduces overhead of mutex locking and increases context switch
rate significantly (which helps to measure and profile the context
switch path).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Collation of some spelling fixes from Colin.
Attemping -> Attempting
intialized -> initialized
missmanaged -> mismanaged
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Now that we have a callback to check if bridge supports a given mode
we can use it in Synopsys Designware HDMI bridge so that we restrict
the number of probbed modes to the ones we can actually display.
Also, there is no need to use mode_fixup() callback as mode_valid()
will handle the mode validation.
NOTE: I also had to change the pdata declaration of mode_valid
custom callback so that the passed modes are const. I also changed
in the platforms I found. Not even compiled it though.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Carlos Palminha <palminha@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Carlo Caione <carlo@caione.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/3d8d449e4d13d2535fa292c75f5fa931de4a4fa8.1495720737.git.joabreu@synopsys.com
A SoC variant of Geode GX1, notably NSC branded SC1100, seems to
report an inverted Device ID in its DIR0 configuration register,
specifically 0xb instead of the expected 0x4.
Catch this presumably quirky version so it's properly recognized
as GX1 and has its cache switched to write-back mode, which provides
a significant performance boost in most workloads.
SC1100's datasheet "Geode™ SC1100 Information Appliance On a Chip",
states in section 1.1.7.1 "Device ID" that device identification
values are specified in SC1100's device errata. These, however,
seem to not have been publicly released.
Wading through a number of boot logs and /proc/cpuinfo dumps found on
pastebin and blogs, this patch should mostly be relevant for a number
of now admittedly aging Soekris NET4801 and PC Engines WRAP devices,
the latter being the platform this issue was discovered on.
Performance impact was verified using "openssl speed", with
write-back caching scaling throughput between -3% and +41%.
Signed-off-by: Christian Sünkenberg <christian.suenkenberg@student.kit.edu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1496596719.26725.14.camel@student.kit.edu
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Currently tsk->thread->load_vec and load_fp are not initialized during
task creation, which can lead to garbage values in these variables (non-zero
values).
These variables will be checked later in restore_math() to validate if the
FP and vector registers are being utilized. Since these values might be
non-zero, the restore_math() will continue to save the FP and vectors even if
they were never utilized by the userspace application. load_fp and load_vec
counters will then overflow (they wrap at 255) and the FP and Altivec will be
finally disabled, but before that condition is reached (counter overflow)
several context switches will have restored FP and vector registers without
need, causing a performance degradation.
Fixes: 70fe3d980f ("powerpc: Restore FPU/VEC/VSX if previously used")
Cc: stable@vger.kernel.org # v4.6+
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Romero <gusbromero@gmail.com>
Acked-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Jiri Pirko says:
====================
mlxsw: Minor cleanup
Fix small issues I noticed during the refactoring.
First patch adds file name comments in the header file to make it clear
what goes where. Second patch fixes a typo and third patch simply aligns
RIF index allocation with similar allocations in the driver.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The way we usually allocate an index is by letting the allocation
function return an error instead of an invalid index.
Do the same for RIF index.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make it clear where functions are defined and move misplaced declaration
to their correct place.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change the firmware file name to be in "mellanox" directory.
This commit is a followup to the linux-firmware commit a4c72696f5f4
("Mellanox: Add firmware for mlxsw_spectrum")
Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Our previous patch (cited below) introduced a regression
for RAW Eth QPs.
Fix it by checking if the QP number provided by user-space
exists, hence allowing steering rules to be added for valid
QPs only.
Fixes: 89c557687a ("net/mlx4_en: Avoid adding steering rules with invalid ring")
Reported-by: Or Gerlitz <gerlitz.or@gmail.com>
Signed-off-by: Talat Batheesh <talatb@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Acked-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Yuval Mintz says:
qed*: Support VF XDP attachment
====================
Each driver queue [Rx, Tx, XDP-forwarding] requires an allocated HW/FW
connection + configured queue-zone.
VF handling by the PF has several limitations that prevented adding the
capability to perform XDP at driver-level:
- The VF assumes there's 1-to-1 correspondance between the VF queue and
the used connection, meaning q<x> is always going to use cid<x>,
whereas for its own queues the PF is acquiring a new cid per each new
queue.
- There's a 1-to-1 correspondate between the VF-queues and the HW queue
zones. While this is necessary for Rx-queues [as the queue-zone
contains the producer], transmission queues can share the underlaying
queue-zone [only shared configuration is coalescing].
But all VF<->PF communication mechanisms assume there's a single
identifier that identify a queue [as queue-zone == queue], while
sharing queue-zones requires passing additional information.
- VFs currently don't try mapping a doorbell bar - there's a small
doorbell window in the regview allowing VFs to doorbell up to 16
connections; but this window isn's wide enough for the added XDP
forwarding queues.
This series is going to add the necessary infrastrucutre to finally let
our VFs support XDP assuming both the PF and VF drivers are sufficiently
new [Legacy support would be retained both for older VFs and older PFs,
but both will be needed for this new support to work].
Basically, the various database driver maintains for its queue-cids
would be revised, and queue-cids would be identified using the
(queue-zone, unique index) pair. The TLV mechanism would then be
extended to allow VFs to communicate that unique-index as well as the
already provided queue-zone. Finally, the VFs would try to map their
doorbell bar and inform their PF that they're using it.
Almost all the changes are in qed, with exception of #3 [which does some
cleanup in qede as well] and #11 that actually enables the feature.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This introduces 2 changes needed for XDP to be supported for VFs:
a. On VF-side, publish the NDO based on qed outputs
b. On PF-side, request qed to allocate sufficient cids per-VF
to allow the child vfs to support it
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The final addition on the qed front -
- VFs would now require their PFs to provide multiple CIDs
- Based on the availability of connections from PF, determine whether
XDP is feasible and share it with qede via dev_info.
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
VFs are currently not mapping their doorbell bar, instead relying
on the small doorbell window they have in their limited regview bar.
In order to increase the number of possible Tx connections [queues]
employeed by VF past 16, we need to start using the doorbell bar if
one such is exposed - VF would communicate this fact to PF which would
return the size-bar internally configured into chip, according to
which the VF would decide whether to actually utilize the doorbell
bar.
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This adds the infrastructure for supporting VFs that want to open
multiple transmission queues on the same queue-zone.
At this point, there are no VFs that actually request this functionality,
but later patches would remedy that.
a. VF and PF would communicate the capability during ACQUIRE;
Legacy VFs would continue on behaving as they do today
b. PF would communicate number of supported CIDs to the VF
and would enforce said limitation
c. Whenever VF passes a request for a given queue configuration
it would also pass an associated index within said queue-zone
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Allow the infrastructure a PF maintains for each one of its VFs
to support multiple queue-cids on a single queue-zone.
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Until now we used to have a single VF legacy compatibility mode,
one that affected the place of the Rx producers of those VFs [mostly].
As PF would soon support allocating CIDs for VFs instead of having
a static CID<->queue configuration for them, we'll need to have
an additional legacy mode since existing VFs would need to continue
on using the older mode of operation.
Change the infrastrucutre so that the legacy would be able to indicate
which of the legacy behaviors is needed for a given VF.
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a queue-cid is allocated, assign an index inside that's
CID's queue-zone.
For PFs and VFS, this number is going to be unique and derive
from a per-queue-zone bitmap, while for PF's VFs queues the
number is currently going to constant; Later, we'd add the
capability of a VF to communicate such an index to its PF.
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We're going to need additional information for queue-cids
that a PF creates for its VFs, so start by refactoring existing
logic used for initializing said struct into receiving a structure
encapsulating the VF-specific information that needs to be provided.
This also introduces QED_QUEUE_CID_SELF - each queue-cid would hold
an indication to whether it belongs to the hw-function holding it
[whether that's a PF or a VF], or else what's the VF id it belongs
to.
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
