Hi Bjorn,
On Mon, Jan 30, 2017 at 03:12:37PM -0600, Bjorn Helgaas wrote:
> Hi Vadim,
>
> On Mon, Jan 30, 2017 at 08:25:52AM -0800, Vadim Lomovtsev wrote:
> > This patch is to address PEM initialization issue
> > which causes network issues.
> >
> > It is nec
On Tue, Jan 31, 2017 at 08:25:25AM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 31, 2017 at 02:28:30AM -0800, Vadim Lomovtsev wrote:
> > Hi Bjorn,
> >
> > On Mon, Jan 30, 2017 at 03:12:37PM -0600, Bjorn Helgaas wrote:
> > > Hi Vadim,
> > >
> > >
On Tue, Jan 31, 2017 at 02:31:09PM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 31, 2017 at 06:57:20AM -0800, Vadim Lomovtsev wrote:
> > On Tue, Jan 31, 2017 at 08:25:25AM -0600, Bjorn Helgaas wrote:
> > > On Tue, Jan 31, 2017 at 02:28:30AM -0800, Vadim Lomovtsev wrote
On Wed, Feb 01, 2017 at 09:18:07AM -0600, Bjorn Helgaas wrote:
> On Wed, Feb 01, 2017 at 04:53:25AM -0800, Vadim Lomovtsev wrote:
> > On Tue, Jan 31, 2017 at 02:31:09PM -0600, Bjorn Helgaas wrote:
> > > On Tue, Jan 31, 2017 at 06:57:20AM -0800, Vadim Lomovtsev wrote:
> >
On Fri, Jan 20, 2017 at 06:12:38AM -0800, Vadim Lomovtsev wrote:
Please ignore this accordingly to mysypo
> Having kernel modules with debug sections consumes a lot of
> hdd space, increases size of kernel rpm, initrd image grows
> and in some cases kernel even can't be inst
.
Signed-off-by: Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com>
---
scripts/package/mkspec | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/package/mkspec b/scripts/package/mkspec
index bb43f15..252d74c 100755
--- a/scripts/package/mkspec
+++ b/scripts/package/
This patch is to address PEM initialization issue
which causes network issues.
It is necessary to search for _HID:PNP0A08 while requesting
PEM resources via ACPI instead of "THRX0002".
Signed-off-by: Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com>
---
drivers/pci/host/pci-t
.
Signed-off-by: Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com>
---
scripts/package/mkspec | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/package/mkspec b/scripts/package/mkspec
index bb43f15..176d8dd 100755
--- a/scripts/package/mkspec
+++ b/scripts/package/
ill
such mapping properly we need to add lmac index to be used while
acpi initialization since at this moment bgx->lmac_count already contains
actual value.
Signed-off-by: Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com>
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 11 ++-
Hi Jon,
On Wed, Mar 15, 2017 at 07:14:38AM -0400, Jon Masters wrote:
> Hi Bjorn, Vadim,
>
> Following up to this old thread...
>
> On 02/01/2017 10:18 AM, Bjorn Helgaas wrote:
> > On Wed, Feb 01, 2017 at 04:53:25AM -0800, Vadim Lomovtsev wrote:
>
> >>&g
Hi all,
Any comments on this ?
WBR,
Vadim
On Mon, Aug 21, 2017 at 07:23:07AM -0400, Vadim Lomovtsev wrote:
> While running nfs/connectathon tests kernel NULL-pointer exception
> has been observed due to races in svcsock.c.
>
> Race is appear when kernel accepts connection by k
x160
[ 6709.203878] [<01bc71c4>] 0x1bc71c4
[ 6709.207967] Code: bad PC value
[ 6709.211061] SMP: stopping secondary CPUs
[ 6709.218830] Starting crashdump kernel...
[ 6709.222749] Bye!
---<-snip>---
Signed-off-by: Vadim Lomovtsev <vlomo...@redhat.com>
---
net/sunrpc/svcsoc
On Fri, Aug 18, 2017 at 07:16:45AM -0400, Jeff Layton wrote:
> On Fri, 2017-08-18 at 07:08 -0400, Vadim Lomovtsev wrote:
> > Hi Jeff,
> >
> > On Fri, Aug 18, 2017 at 06:27:32AM -0400, Jeff Layton wrote:
> > > On Fri, 2017-08-18 at 06:00 -0400, Vadim Lomovtsev wr
Hi Jeff,
On Fri, Aug 18, 2017 at 06:27:32AM -0400, Jeff Layton wrote:
> On Fri, 2017-08-18 at 06:00 -0400, Vadim Lomovtsev wrote:
> > While running nfs/connectathon tests kernel NULL-pointer exception
> > has been observed due to races in svcsock.c.
> >
> > Race is
On Fri, May 12, 2017 at 10:18:46AM -0700, Vadim Lomovtsev wrote:
Hi Lorenzo,
> Hi Lorenzo
>
> On Fri, May 12, 2017 at 04:50:40PM +0100, Lorenzo Pieralisi wrote:
> > Hi Vadim,
> >
> > On Fri, May 12, 2017 at 05:44:05AM -0700, Vadim Lomovtsev wrote:
> > > Hi
ested at dual-socketed system with Cavium ThunderX SoC.
Tested with 4.11 kernel.
No issues observed, numa_node value set appropriately for pci devices.
Tested-by: Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com>
> --
> 2.10.0
>
WBR,
Vadim
Hi Lorenzo
On Fri, May 12, 2017 at 04:50:40PM +0100, Lorenzo Pieralisi wrote:
> Hi Vadim,
>
> On Fri, May 12, 2017 at 05:44:05AM -0700, Vadim Lomovtsev wrote:
> > Hi Lorenzo,
> >
> > Are there any news related to these patches ?
>
> Not really, I hav
Hi Lorenzo,
Are there any news related to these patches ?
WBR,
Vadim
. Always
set.
<2> RRRO 1 1 ACS P2P request redirect. Always
set.
<1> TBRO 1 1 ACS transaction blocking. Always
set.
<0> SVRO 1 1 ACS source validation. Always set.
-
forwarding and validation features enabled.
Current quirk implementation doesn't take into account PCIERCs which
also needs to be quirked. So the pci device id check mask is updated
and check of device ID moved into separate function.
Signed-off-by: Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.
Hi guys,
Sorry for annoying topic ..
Could you please provide your comments/objections on this if any ?
WBR,
Vadim
On Mon, Sep 18, 2017 at 01:48:01AM -0700, Vadim Lomovtsev wrote:
> This commit makes Cavium PCI ACS quirk applicable only to Cavium
> ThunderX (CN81/83/88XX) PCIE Root Ports
On Wed, Sep 20, 2017 at 10:31:51AM -0600, Alex Williamson wrote:
> On Mon, 18 Sep 2017 01:48:01 -0700
> Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com> wrote:
>
> > This commit makes Cavium PCI ACS quirk applicable only to Cavium
> > ThunderX (CN81/83/88XX) PCIE R
Hi Bjorn,
Would you please consider to take this patch ?
It is required to provide correct ACS mask for CN8xxx PCI root ports.
WBR,
Vadim
On Wed, Sep 27, 2017 at 02:18:54PM -0600, Alex Williamson wrote:
> On Wed, 27 Sep 2017 11:20:39 -0700
> Vadim Lomovtsev <vadim.lomovt...@caviumnet
X ACS quirk only to Root Ports".
>
> On Wed, Sep 27, 2017 at 11:20:39AM -0700, Vadim Lomovtsev wrote:
> > This commit makes Cavium PCI ACS quirk applicable only to Cavium
> > ThunderX (CN8XXX) family PCIE Root Ports which has limited PCI capabilities
> > in terms o
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
version 7:
- update patch description accordingly to review comments;
- split for two patches: for ACS mask change and device id match change;
- remove macro #define of ACS flags, put it back to quirk function;
- remove '__inline_' from dev
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
The Cavium ThunderX (CN8XXX) family PCIe Root Ports has limited PCI
capabilities in terms of no ACS support advertisement. However,
the RTL internally implements similar protection as if ACS had
completion/request redirection, upstream forw
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
This commit changes the Cavium PCI ACS quirk appliance only to
Cavium CN8xxx PICe Root Ports.
Current quirk implementation doesn't take into account PCIe Root Ports
which needs to be quirked. So the pci device id check mask is u
Hi all,
Are there any updates on this ?
Comments/objections/acks/nacks ?
WBBR,
Vadim
On Fri, Sep 08, 2017 at 10:10:30AM +0200, Jan Glauber wrote:
> Using vfio-pci on a combination of cn8xxx and some PCI devices results in
> a kernel panic. This is triggered by issuing a bus or a slot reset
> on
On Tue, Sep 12, 2017 at 10:15:45AM -0600, Alex Williamson wrote:
> On Tue, 12 Sep 2017 04:55:16 -0700
> Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com> wrote:
>
> > This commit makes PIC ACS quirk applicable only to Cavium PCIE devices
> > and Cavium PCIE Root
To my previous email, please ignore this for now:
> Would the resetting of RR/CR/UF/SV bits be more correct here ?
WBR,
Vadim
range values checkings.
Signed-off-by: Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com>
---
drivers/pci/quirks.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index a4d3361..11ca951
forwarding and validation features enabled.
Current quirk implementation doesn't take into account PCIERCs which
also needs to be quirked. So the pci device id check mask is updated
and check of device ID moved into separate function.
Signed-off-by: Vadim Lomovtsev <vadim.lom
Hi guys,
Could you please consider to review following patch?
For v5 changes:
- ACS mask comment has been updated.
- comment has been added for device id filtering mask at match
function to provide explantion of CN8xxx devid scheme.
WBR,
Vadim
On Mon, Sep 25, 2017 at 06:08:40AM -0700, Vadim
On Tue, Sep 26, 2017 at 09:43:43AM -0600, Alex Williamson wrote:
> On Mon, 25 Sep 2017 06:08:40 -0700
> Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com> wrote:
>
> > This commit makes Cavium PCI ACS quirk applicable only to Cavium
> > ThunderX (CN8XXX) family PCIE R
On Tue, Sep 26, 2017 at 09:00:26AM -0700, Vadim Lomovtsev wrote:
> On Tue, Sep 26, 2017 at 09:43:43AM -0600, Alex Williamson wrote:
> > On Mon, 25 Sep 2017 06:08:40 -0700
> > Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com> wrote:
> >
> > > This commit m
forwarding and validation features enabled.
Current quirk implementation doesn't take into account PCIERCs which
also needs to be quirked. So the pci device id check mask is updated
and check of device ID moved into separate function.
Signed-off-by: Vadim Lomovtsev <vadim.lom
Hi guys,
I've found one typo (0xa00 instead of 0xa000 at code comment) and v6 has it
fixed.
I bring my apologies for that, could you please review this patch once again.
WBR,
Vadim
On Wed, Sep 27, 2017 at 11:20:39AM -0700, Vadim Lomovtsev wrote:
> This commit makes Cavium PCI ACS qu
Hi Bjorn,
On Wed, Sep 27, 2017 at 02:18:54PM -0600, Alex Williamson wrote:
> On Wed, 27 Sep 2017 11:20:39 -0700
> Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com> wrote:
>
> > This commit makes Cavium PCI ACS quirk applicable only to Cavium
> > ThunderX (CN8XXX) f
On Mon, Aug 21, 2017 at 06:42:07AM -0400, Jeff Layton wrote:
> On Mon, 2017-08-21 at 04:56 -0400, Vadim Lomovtsev wrote:
> > While running nfs/connectathon tests kernel NULL-pointer exception
> > has been observed due to races in svcsock.c.
> >
> > Race is appear whe
0x30
[ 6709.197624] [] secondary_start_kernel+0x13c/0x160
[ 6709.203878] [<01bc71c4>] 0x1bc71c4
[ 6709.207967] Code: bad PC value
[ 6709.211061] SMP: stopping secondary CPUs
[ 6709.218830] Starting crashdump kernel...
[ 6709.222749] Bye!
---<-snip>---
Signed-off-by: Vadim Lomovtsev
0x30
[ 6709.197624] [] secondary_start_kernel+0x13c/0x160
[ 6709.203878] [<01bc71c4>] 0x1bc71c4
[ 6709.207967] Code: bad PC value
[ 6709.211061] SMP: stopping secondary CPUs
[ 6709.218830] Starting crashdump kernel...
[ 6709.222749] Bye!
---<-snip>---
Signed-off-by: Vadim Lomovtsev
0x30
[ 6709.197624] [] secondary_start_kernel+0x13c/0x160
[ 6709.203878] [<01bc71c4>] 0x1bc71c4
[ 6709.207967] Code: bad PC value
[ 6709.211061] SMP: stopping secondary CPUs
[ 6709.218830] Starting crashdump kernel...
[ 6709.222749] Bye!
---<-snip>---
Signed-off-by: Vadim Lomovtsev
Sorry guys, please ignore this - being sent by mistake.
Have some typos at comments by copy-paste, will correct and re-send
Vadim
On Mon, Aug 21, 2017 at 04:44:45AM -0400, Vadim Lomovtsev wrote:
> While running nfs/connectathon tests kernel NULL-pointer exception
> has been observ
On Fri, Aug 25, 2017 at 06:01:28PM -0400, J. Bruce Fields wrote:
> On Fri, Aug 18, 2017 at 06:00:47AM -0400, Vadim Lomovtsev wrote:
> > While running nfs/connectathon tests kernel NULL-pointer exception
> > has been observed due to races in svcsock.c.
> >
> > Race is
Hi all,
Following issue has been observed while running stress-ng test
at arm64-based board. Please find short summary below.
Similar issue was reported a while ago: https://lkml.org/lkml/2017/1/20/101
but in my case I have totally "empty" setup having nothing special running
except test itself
On Thu, Oct 19, 2017 at 06:26:45AM -0500, Bjorn Helgaas wrote:
> On Tue, Oct 17, 2017 at 05:47:37AM -0700, Vadim Lomovtsev wrote:
> > From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
> >
> > version 7:
> > - update patch description accordingly to review comm
On Wed, Dec 13, 2017 at 12:45:50AM +0100, Rafael J. Wysocki wrote:
> On Tuesday, December 12, 2017 4:59:19 PM CET Vadim Lomovtsev wrote:
> > Hi guys,
> >
> > While running LTP tests I've faced kernel crash caused by ltp_acpi test
> > case.
> > I have ACPI sup
rfaces. However, it seems that such calls was put there
intentionally,
without ACPI state check, as part of kernel testing strategy.
WBR,
Vadim
>
> > -Original Message-
> > From: Vadim Lomovtsev [mailto:vadim.lomovt...@caviumnetworks.com]
> > Sent: Tuesday
On Wed, Dec 13, 2017 at 05:52:38PM +0100, Rafael J. Wysocki wrote:
> On Wed, Dec 13, 2017 at 3:55 PM, Vadim Lomovtsev
> <vadim.lomovt...@caviumnetworks.com> wrote:
> > On Wed, Dec 13, 2017 at 12:45:50AM +0100, Rafael J. Wysocki wrote:
> >> On Tuesday, December 12
On Wed, Dec 13, 2017 at 05:48:49PM +0100, Rafael J. Wysocki wrote:
> On Wed, Dec 13, 2017 at 3:52 PM, Vadim Lomovtsev
> <vadim.lomovt...@caviumnetworks.com> wrote:
> > On Tue, Dec 12, 2017 at 09:52:21PM +, Moore, Robert wrote:
> >> Another way to look at thi
Hi guys,
While running LTP tests I've faced kernel crash caused by ltp_acpi test case.
I have ACPI support enabled in kernel but kernel is boot with FDT having ACPI
disabled. The ltp_acpi test case application is built along with ltp_acpi_cmds
module to run ACPI tests.
So my question is - should
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
While having kernel built with ACPI support enabled and booted over FDT,
the ltp_acpi test from LTP suite causes kernel crash while calling
acpi_ns_walk_namespace(). The acpi_get_devices is high level wrapper for
it, so we need to protect
On Thu, Oct 19, 2017 at 01:50:10PM -0500, Bjorn Helgaas wrote:
> On Thu, Oct 19, 2017 at 04:59:21AM -0700, Vadim Lomovtsev wrote:
> > On Thu, Oct 19, 2017 at 06:26:45AM -0500, Bjorn Helgaas wrote:
> > > On Tue, Oct 17, 2017 at 05:47:37AM -0700, Vadim Lomovtsev wrote:
> > &
Self NACK to this one, subject line typo, sorry.
Vadim
On Thu, Jan 18, 2018 at 07:42:40AM -0800, Vadim Lomovtsev wrote:
> From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
>
> It was found that ethtool provides unexisting module name while
> it queries the specif
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
It was found that ethtool provides unexisting module name while
it queries the specified network device for associated driver
information.
This patch is to correct Cavium CN88xx Thunder nicvf/nicpf modules
names 'nicvf' to 'thunder
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
It was found that ethtool provides unexisting module name while
it queries the specified network device for associated driver
information.
This patch is to correct Cavium CN88xx Thunder nicvf/nicpf modules
names 'nicvf' to 'thunder
Self NACK here: modules names has to contain dashes instead
of underscores, as it defined at sources (or update modules
DRV_NAME definitions whithin the source files with underscores).
Shame on me.
Vadim
On Thu, Jan 18, 2018 at 07:53:09AM -0800, Vadim Lomovtsev wrote:
> From: Vadim Lomovt
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
It was found that ethtool provides unexisting module name while
it queries the specified network device for associated driver
information. Then user tries to unload that module by provided
module name and fails.
This happens because e
On Wed, Jan 24, 2018 at 04:27:37PM -0500, David Miller wrote:
> From: Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com>
> Date: Mon, 22 Jan 2018 06:13:27 -0800
>
> > From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
> >
> > It was found that ethtoo
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
It was found that ethtool provides unexisting module name while
it queries the specified network device for associated driver
information. Then user tries to unload that module by provided
module name and fails.
This happens because e
Hi all,
I bring my Apologise for wasting your time, but ..
May I ask for some clarification.. When we're speaking of 'posting patches
shortly'
does it mean to send them in next few hours ?
Or would it be more acceptable to post one version per day
even for very small changes in between ?
Hi Willy,
Thank you for your opinion, it's very helpful.
WBR,
Vadim
On Fri, Apr 06, 2018 at 09:21:46PM +0200, Willy Tarreau wrote:
> Hi Vadim,
>
> On Fri, Apr 06, 2018 at 11:29:16AM -0700, Vadim Lomovtsev wrote:
> > Hi all,
> >
> > I bring my Apol
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
It is too expensive to pass u64 values via linked list, instead
allocate array for them by overall number of mac addresses from netdev.
This eventually removes multiple kmalloc() calls, aviod memory
fragmentation and allow to put singl
Hi Robin,
On Fri, Apr 06, 2018 at 12:48:40PM +0100, Robin Murphy wrote:
> On 06/04/18 12:14, Vadim Lomovtsev wrote:
> > From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
> >
> > It is too expensive to pass u64 values via linked list, instead
> > allocate array
On Fri, Apr 06, 2018 at 06:47:26AM -0500, Gustavo A. R. Silva wrote:
>
>
> On 04/06/2018 06:43 AM, Vadim Lomovtsev wrote:
> > Hi Gustavo,
> >
> > On Fri, Apr 06, 2018 at 06:36:28AM -0500, Gustavo A. R. Silva wrote:
> > > Hi Vadim,
> > >
> &
Hi Gustavo,
On Fri, Apr 06, 2018 at 06:36:28AM -0500, Gustavo A. R. Silva wrote:
> Hi Vadim,
>
> On 04/06/2018 06:14 AM, Vadim Lomovtsev wrote:
> > From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
> >
> > It is too expensive to pass u64 values via linked
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
It is too expensive to pass u64 values via linked list, instead
allocate array for them by overall number of mac addresses from netdev.
This eventually removes multiple kmalloc() calls, aviod memory
fragmentation and allow to put singl
Hi guys,
Please give me couple days to workout solution for this.
I'll post patch for this as soon as I done with my testing.
WBR,
Vadim
On Tue, Apr 03, 2018 at 05:04:23PM -0500, Gustavo A. R. Silva wrote:
> Add null check on kmalloc() return value in order to prevent
> a null pointer
Hi Christoph,
Thank you for your feedback and time.
On Thu, Apr 05, 2018 at 08:07:48AM -0700, Christoph Hellwig wrote:
> > struct xcast_addr_list {
> > - struct list_head list;
> > int count;
> > + u64 mc[0];
>
> Please use the standard C99 syntax here:
>
>
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
It is too expensive to pass u64 values via linked list, instead
allocate array for them by overall number of mac addresses from netdev.
This eventually removes multiple kmalloc() calls, aviod memory
fragmentation and allow to put singl
[correct Roberts' address]
On Thu, Apr 05, 2018 at 07:57:56AM -0700, Vadim Lomovtsev wrote:
> From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
>
> It is too expensive to pass u64 values via linked list, instead
> allocate array for them by overall number of mac add
On Sun, Apr 08, 2018 at 12:42:00PM -0400, David Miller wrote:
> From: Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com>
> Date: Fri, 6 Apr 2018 12:53:54 -0700
>
> > @@ -1929,7 +1929,7 @@ static void nicvf_set_rx_mode_task(struct work_
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
It is too expensive to pass u64 values via linked list, instead
allocate array for them by overall number of mac addresses from netdev.
This eventually removes multiple kmalloc() calls, aviod memory
fragmentation and allow to put singl
Self-NACK here, because of https://lkml.org/lkml/2018/4/6/724
Sorry for noise.
Vadim
On Fri, Apr 06, 2018 at 07:04:43AM -0700, Vadim Lomovtsev wrote:
> From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
>
> It is too expensive to pass u64 values via linked list, instead
&
On Fri, Apr 06, 2018 at 11:06:03AM -0400, David Miller wrote:
> From: Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com>
> Date: Fri, 6 Apr 2018 04:14:25 -0700
>
> > diff --git a/drivers/net/ethernet/cavium/thunder/nic.h
> > b/drivers/net/ethernet/cavium/thunder/n
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
It is too expensive to pass u64 values via linked list, instead
allocate array for them by overall number of mac addresses from netdev.
This eventually removes multiple kmalloc() calls, aviod memory
fragmentation and allow to put singl
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
The ThunderX NIC has two Ethernet Interfaces (BGX) each of them could has
up to four Logical MACs configured. Each of BGX has 32 filters to be
configured for filtering ingress packets. The number of filters available
to particular LMAC is
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
By default CN88XX BGX accepts all incoming multicast and broadcast
packets and filtering is disabled. The nic driver doesn't provide
an ability to change such behaviour.
This series is to implement DMAC filtering management for CN88XX
nic
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
The ThunderX NIC could be partitioned to up to 128 VFs and thus
represented to system. Each VF is mapped to pair BGX:LMAC, and each of VF
is configured by kernel individually. Eventually the bunch of VFs could be
mapped onto same pair BG
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
The ndo_set_rx_mode() is called from atomic context which causes
messages response timeouts while VF to PF communication via MSIx.
To get rid of that we're copy passed mc list, parse flags and queue
handling of kernel request to ordered wor
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
The ThunderX NIC has set of registers which allows to configure
filter policy for ingress packets. There are three possible regimes
of filtering multicasts, broadcasts and unicasts: accept all, reject all
and accept filter allowed only.
C
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
The kernel calls ndo_set_rx_mode() callback supplying it will all necessary
info, such as device state flags, multicast mac addresses list and so on.
Since we have only 128 bits to communicate with PF we need to initiate
several requests
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
This commit is to add message handling for ndo_set_rx_mode()
callback at PF side.
Signed-off-by: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nic_main.c | 45 +++---
1 file
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
The kernel calls ndo_set_rx_mode() callback from atomic context which
causes messaging timeouts between VF and PF (as they’re implemented
via MSIx). So in order to handle ndo_set_rx_mode() we need to get rid of it.
This commit impl
Hi David,
Thanks for feedback.
On Tue, Mar 27, 2018 at 01:28:22PM -0400, David Miller wrote:
> From: Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com>
> Date: Tue, 27 Mar 2018 08:07:29 -0700
>
> > From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
> >
>
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
The ThunderX NIC has set of registers which allows to configure
filter policy for ingress packets. There are three possible regimes
of filtering multicasts, broadcasts and unicasts: accept all, reject all
and accept filter allowed only.
C
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
The ndo_set_rx_mode() is called from atomic context which causes
messages response timeouts while VF to PF communication via MSIx.
To get rid of that we're copy passed mc list, parse flags and queue
handling of kernel request to ordered wor
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
The kernel calls ndo_set_rx_mode() callback supplying it will all necessary
info, such as device state flags, multicast mac addresses list and so on.
Since we have only 128 bits to communicate with PF we need to initiate
several requests
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
The ThunderX NIC has two Ethernet Interfaces (BGX) each of them could has
up to four Logical MACs configured. Each of BGX has 32 filters to be
configured for filtering ingress packets. The number of filters available
to particular LMAC is
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
This commit is to add message handling for ndo_set_rx_mode()
callback at PF side.
Signed-off-by: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nic_main.c | 45 +++---
1 file
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
The kernel calls ndo_set_rx_mode() callback from atomic context which
causes messaging timeouts between VF and PF (as they’re implemented via
MSIx). So in order to handle ndo_set_rx_mode() we need to get rid of it.
This commit impl
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
By default CN88XX BGX accepts all incoming multicast and broadcast
packets and filtering is disabled. The nic driver doesn't provide
an ability to change such behaviour.
This series is to implement DMAC filtering management for CN88XX
nic
From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
The ThunderX NIC could be partitioned to up to 128 VFs and thus
represented to system. Each VF is mapped to pair BGX:LMAC, and each of VF
is configured by kernel individually. Eventually the bunch of VFs could be
mapped onto same pair BG
On Sat, Mar 31, 2018 at 10:07:30PM -0400, David Miller wrote:
> From: Vadim Lomovtsev <vadim.lomovt...@caviumnetworks.com>
> Date: Fri, 30 Mar 2018 04:59:46 -0700
>
> > From: Vadim Lomovtsev <vadim.lomovt...@cavium.com>
> >
> > By default CN88XX BGX accep
From: Vadim Lomovtsev
The ThunderX NIC has set of registers which allows to configure
filter policy for ingress packets. There are three possible regimes
of filtering multicasts, broadcasts and unicasts: accept all, reject all
and accept filter allowed only.
Current implementation has enum
From: Vadim Lomovtsev
The kernel calls ndo_set_rx_mode() callback supplying it will all necessary
info, such as device state flags, multicast mac addresses list and so on.
Since we have only 128 bits to communicate with PF we need to initiate
several requests to PF with small/short operation
From: Vadim Lomovtsev
This commit is to add message handling for ndo_set_rx_mode()
callback at PF side.
Signed-off-by: Vadim Lomovtsev
---
drivers/net/ethernet/cavium/thunder/nic_main.c | 45 +++---
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/net
From: Vadim Lomovtsev
The kernel calls ndo_set_rx_mode() callback from atomic context which
causes messaging timeouts between VF and PF (as they’re implemented
via MSIx). So in order to handle ndo_set_rx_mode() we need to get rid of it.
This commit implements necessary workqueue related
From: Vadim Lomovtsev
The ndo_set_rx_mode() is called from atomic context which causes
messages response timeouts while VF to PF communication via MSIx.
To get rid of that we're copy passed mc list, parse flags and queue
handling of kernel request to ordered workqueue.
Signed-off-by: Vadim
From: Vadim Lomovtsev
The ThunderX NIC could be partitioned to up to 128 VFs and thus
represented to system. Each VF is mapped to pair BGX:LMAC, and each of VF
is configured by kernel individually. Eventually the bunch of VFs could be
mapped onto same pair BGX:LMAC and thus could cause several
1 - 100 of 218 matches
Mail list logo
