* Re: [PATCH v2 net] inet: frags: rework rhashtable dismantle
From: Eric Dumazet @ 2018-10-02 13:16 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: David Miller, netdev, Eric Dumazet, Thomas Graf, Herbert Xu
In-Reply-To: <CACT4Y+YH92M_X7h21W-unhp73tXV+itxuL0JjrfEd4B4Lohjig@mail.gmail.com>
On Tue, Oct 2, 2018 at 1:19 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Oct 2, 2018 at 7:49 AM, Eric Dumazet <edumazet@google.com> wrote:
>
>
> Does inet_frag_kill() hold fq->lock? I am missing how inet_frag_kill()
> and inet_frags_exit_net() are synchronized.
> Since you use smp_store_release()/READ_ONCE() they seem to run in
> parallel. But then isn't it possible that inet_frag_kill() reads
> nf->dead == 0, then inet_frags_exit_net() sets nf->dead, and then we
> have the same race on concurrent removal? Or, isn't it possible that
> inet_frag_kill() reads nf->dead == 1, but does not set
> INET_FRAG_HASH_DEAD yet, and then inet_frags_free_cb() misses the
> INET_FRAG_HASH_DEAD flag?
>
Yes this is kind of implied in my patch.
I put the smp_store_release() and READ_ONCE exactly to document the
possible races.
This was the reason for my attempt in V1, doing a walk, but Herbert
said walk was not designed for doing deletes.
Proper synch will need a synchronize_rcu(), and thus a future
conversion in net-next because we can not really
add new synchronize_rcu() calls in an (struct
pernet_operations.)exit() without considerable performance hit of
netns dismantles.
So this will require a conversion of all inet_frags_exit_net() callers
to .exit_batch() to mitigate the cost.
I thought of synchronize_rcu_bh() but this beast is going away soon anyway.
^ permalink raw reply
* [PATCH net-next 1/2] qed: Add driver support for 20G link speed.
From: Sudarsana Reddy Kalluru @ 2018-10-02 13:16 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon
In-Reply-To: <20181002131612.10859-1-sudarsana.kalluru@cavium.com>
Add driver support for configuring/reading the 20G link speed.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 3 +++
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 2 ++
drivers/net/ethernet/qlogic/qed/qed_main.c | 11 +++++++++++
include/linux/qed/qed_if.h | 9 +++++----
4 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 0fbeafe..7ceb2b9 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -2679,6 +2679,9 @@ static int qed_hw_get_nvm_info(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
case NVM_CFG1_PORT_DRV_LINK_SPEED_10G:
link->speed.forced_speed = 10000;
break;
+ case NVM_CFG1_PORT_DRV_LINK_SPEED_20G:
+ link->speed.forced_speed = 20000;
+ break;
case NVM_CFG1_PORT_DRV_LINK_SPEED_25G:
link->speed.forced_speed = 25000;
break;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_hsi.h b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
index d4d0838..56578f8 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_hsi.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
@@ -13154,6 +13154,7 @@ struct nvm_cfg1_port {
#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_OFFSET 0
#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G 0x1
#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G 0x2
+#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G 0x4
#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G 0x8
#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_40G 0x10
#define NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_50G 0x20
@@ -13164,6 +13165,7 @@ struct nvm_cfg1_port {
#define NVM_CFG1_PORT_DRV_LINK_SPEED_AUTONEG 0x0
#define NVM_CFG1_PORT_DRV_LINK_SPEED_1G 0x1
#define NVM_CFG1_PORT_DRV_LINK_SPEED_10G 0x2
+#define NVM_CFG1_PORT_DRV_LINK_SPEED_20G 0x3
#define NVM_CFG1_PORT_DRV_LINK_SPEED_25G 0x4
#define NVM_CFG1_PORT_DRV_LINK_SPEED_40G 0x5
#define NVM_CFG1_PORT_DRV_LINK_SPEED_50G 0x6
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 2094d86..75d217a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1337,6 +1337,9 @@ static int qed_set_link(struct qed_dev *cdev, struct qed_link_params *params)
if (params->adv_speeds & QED_LM_10000baseKR_Full_BIT)
link_params->speed.advertised_speeds |=
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G;
+ if (params->adv_speeds & QED_LM_20000baseKR2_Full_BIT)
+ link_params->speed.advertised_speeds |=
+ NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G;
if (params->adv_speeds & QED_LM_25000baseKR_Full_BIT)
link_params->speed.advertised_speeds |=
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G;
@@ -1503,6 +1506,9 @@ static void qed_fill_link(struct qed_hwfn *hwfn,
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G)
if_link->advertised_caps |= QED_LM_10000baseKR_Full_BIT;
if (params.speed.advertised_speeds &
+ NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G)
+ if_link->advertised_caps |= QED_LM_20000baseKR2_Full_BIT;
+ if (params.speed.advertised_speeds &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G)
if_link->advertised_caps |= QED_LM_25000baseKR_Full_BIT;
if (params.speed.advertised_speeds &
@@ -1523,6 +1529,9 @@ static void qed_fill_link(struct qed_hwfn *hwfn,
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G)
if_link->supported_caps |= QED_LM_10000baseKR_Full_BIT;
if (link_caps.speed_capabilities &
+ NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G)
+ if_link->supported_caps |= QED_LM_20000baseKR2_Full_BIT;
+ if (link_caps.speed_capabilities &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G)
if_link->supported_caps |= QED_LM_25000baseKR_Full_BIT;
if (link_caps.speed_capabilities &
@@ -1559,6 +1568,8 @@ static void qed_fill_link(struct qed_hwfn *hwfn,
if_link->lp_caps |= QED_LM_1000baseT_Full_BIT;
if (link.partner_adv_speed & QED_LINK_PARTNER_SPEED_10G)
if_link->lp_caps |= QED_LM_10000baseKR_Full_BIT;
+ if (link.partner_adv_speed & QED_LINK_PARTNER_SPEED_20G)
+ if_link->lp_caps |= QED_LM_20000baseKR2_Full_BIT;
if (link.partner_adv_speed & QED_LINK_PARTNER_SPEED_25G)
if_link->lp_caps |= QED_LM_25000baseKR_Full_BIT;
if (link.partner_adv_speed & QED_LINK_PARTNER_SPEED_40G)
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index 8cd3464..dee3c9c 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -670,10 +670,11 @@ enum qed_link_mode_bits {
QED_LM_1000baseT_Half_BIT = BIT(4),
QED_LM_1000baseT_Full_BIT = BIT(5),
QED_LM_10000baseKR_Full_BIT = BIT(6),
- QED_LM_25000baseKR_Full_BIT = BIT(7),
- QED_LM_40000baseLR4_Full_BIT = BIT(8),
- QED_LM_50000baseKR2_Full_BIT = BIT(9),
- QED_LM_100000baseKR4_Full_BIT = BIT(10),
+ QED_LM_20000baseKR2_Full_BIT = BIT(7),
+ QED_LM_25000baseKR_Full_BIT = BIT(8),
+ QED_LM_40000baseLR4_Full_BIT = BIT(9),
+ QED_LM_50000baseKR2_Full_BIT = BIT(10),
+ QED_LM_100000baseKR4_Full_BIT = BIT(11),
QED_LM_COUNT = 11
};
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 0/2] qed*: Driver support for 20G link speed.
From: Sudarsana Reddy Kalluru @ 2018-10-02 13:16 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, Sudarsana Reddy Kalluru
From: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
The patch series adds driver support for configuring/reading the 20G link
speed.
Please consider applying this to "net-next".
Sudarsana Reddy Kalluru (2):
qed: Add driver support for 20G link speed.
qede: Add driver support for 20G link speed.
drivers/net/ethernet/qlogic/qed/qed_dev.c | 3 +++
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 2 ++
drivers/net/ethernet/qlogic/qed/qed_main.c | 11 +++++++++++
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 9 +++++++++
include/linux/qed/qed_if.h | 9 +++++----
5 files changed, 30 insertions(+), 4 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH v3] PCI: Reprogram bridge prefetch registers on resume
From: Bjorn Helgaas @ 2018-10-02 20:03 UTC (permalink / raw)
To: Thomas Martitz
Cc: andy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ, Linux PM, Linux PCI,
Wysocki, Rafael J, Linux Kernel, Daniel Drake, Keith Busch,
netdev, nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Bjorn Helgaas,
rchang-eYqpPyKDWXRBDgjK7y7TUQ, Linux Upstreaming Team,
David Miller, Jon Derrick, Heiner Kallweit
In-Reply-To: <7b0a5388-5b3a-a6e0-347f-94f87fc2e540-UCKwuKHb1aVAfugRpC6u6w@public.gmane.org>
Hi Thomas,
On Mon, Oct 01, 2018 at 04:25:06PM +0200, Thomas Martitz wrote:
> Am 01.10.18 um 06:57 schrieb Daniel Drake:
> > On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz <kugel@rockbox.org> wrote:
> > > The latest iteration does not work on my HP system. The GPU fails to
> > > power up just like the unpatched kernel.
> >
> > That's weird, I would not expect a behaviour change in the latest
> > patch. pci_restore_config_dword() has some debug messages, could you
> > please make them visible and show logs again?
> > Also remind us of the PCI device address of the parent bridge (lspci -vt)
>
> I'll follow up with more the requested information on bugzilla
> (Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069).
>
> On a quick re-check, it seems to depend on if I used the eGPU before
> the initial suspend. If I run glxgears (with DRI_PRIME=1) before suspend it
> seems fine.
Does the patch ([1]) make things *worse* compared to v4.19-rc5?
If so, I'll drop the patch until we figure this out. But if the GPU
power issue also occurs in v4.19-rc5, I think we can assume it's a
different problem and we can go ahead and merge [1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=for-linus&id=083874549fdfefa629dfa752785e20427dde1511
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* [PATCH net-next 2/2] qede: Add driver support for 20G link speed.
From: Sudarsana Reddy Kalluru @ 2018-10-02 13:16 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon
In-Reply-To: <20181002131612.10859-1-sudarsana.kalluru@cavium.com>
Add driver support for reading/configuring the 20G link speed via ethtool.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index 19652cd..7ff50b4 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -420,6 +420,7 @@ struct qede_link_mode_mapping {
{QED_LM_1000baseT_Half_BIT, ETHTOOL_LINK_MODE_1000baseT_Half_BIT},
{QED_LM_1000baseT_Full_BIT, ETHTOOL_LINK_MODE_1000baseT_Full_BIT},
{QED_LM_10000baseKR_Full_BIT, ETHTOOL_LINK_MODE_10000baseKR_Full_BIT},
+ {QED_LM_20000baseKR2_Full_BIT, ETHTOOL_LINK_MODE_20000baseKR2_Full_BIT},
{QED_LM_25000baseKR_Full_BIT, ETHTOOL_LINK_MODE_25000baseKR_Full_BIT},
{QED_LM_40000baseLR4_Full_BIT, ETHTOOL_LINK_MODE_40000baseLR4_Full_BIT},
{QED_LM_50000baseKR2_Full_BIT, ETHTOOL_LINK_MODE_50000baseKR2_Full_BIT},
@@ -535,6 +536,14 @@ static int qede_set_link_ksettings(struct net_device *dev,
}
params.adv_speeds = QED_LM_10000baseKR_Full_BIT;
break;
+ case SPEED_20000:
+ if (!(current_link.supported_caps &
+ QED_LM_20000baseKR2_Full_BIT)) {
+ DP_INFO(edev, "20G speed not supported\n");
+ return -EINVAL;
+ }
+ params.adv_speeds = QED_LM_20000baseKR2_Full_BIT;
+ break;
case SPEED_25000:
if (!(current_link.supported_caps &
QED_LM_25000baseKR_Full_BIT)) {
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 5/5] soc/fsl_qbman: export coalesce change API
From: Li Yang @ 2018-10-02 20:07 UTC (permalink / raw)
To: madalin.bucur
Cc: Roy Pledge, claudiu.manoil, Catalin Marinas, Scott Wood,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linuxppc-dev, lkml, Netdev
In-Reply-To: <AM6PR04MB400877EC0C140A7D919AEF41ECE80@AM6PR04MB4008.eurprd04.prod.outlook.com>
On Tue, Oct 2, 2018 at 1:08 AM Madalin-cristian Bucur
<madalin.bucur@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Li Yang [mailto:leoyang.li@nxp.com]
> > Sent: Tuesday, October 2, 2018 12:50 AM
> > To: Madalin-cristian Bucur <madalin.bucur@nxp.com>
> > Cc: Roy Pledge <roy.pledge@nxp.com>; Claudiu Manoil
> > <claudiu.manoil@nxp.com>; Catalin Marinas <catalin.marinas@arm.com>; Scott
> > Wood <oss@buserror.net>; moderated list:ARM/FREESCALE IMX / MXC ARM
> > ARCHITECTURE <linux-arm-kernel@lists.infradead.org>; linuxppc-dev
> > <linuxppc-dev@lists.ozlabs.org>; lkml <linux-kernel@vger.kernel.org>
> > Subject: Re: [PATCH v2 5/5] soc/fsl_qbman: export coalesce change API
> >
> > On Fri, Sep 28, 2018 at 3:45 AM Madalin Bucur <madalin.bucur@nxp.com>
> > wrote:
> > >
> > > Export the API required to control the QMan portal interrupt coalescing
> > > settings.
> >
> > These are new APIs not just old APIs being exported. What is the user
> > of these APIs? Is the user being submitted? We cannot have APIs in
> > kernel that has no users.
>
> Hi,
>
> These are new APIs that will be used in the DPAA Ethernet driver.
> Changes for the DPAA QBMan and DPAA Ethernet follow different paths upstream
> so the Ethernet driver patch that makes use of these APIs will be sent when
> these changes reach the net-next/master tree.
Applied for next after changing from "export API" to "add API" in the
introduction and updated the subsystem prefix.
Regards,
Leo
^ permalink raw reply
* Re: [PATCH v2 net] inet: frags: rework rhashtable dismantle
From: Dmitry Vyukov @ 2018-10-02 13:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Eric Dumazet, Thomas Graf, Herbert Xu
In-Reply-To: <CANn89iJy3J4tyMeTxD+F5ipsSevvtc=SQNhef8Ghd4NpCqkjww@mail.gmail.com>
On Tue, Oct 2, 2018 at 3:16 PM, Eric Dumazet <edumazet@google.com> wrote:
> On Tue, Oct 2, 2018 at 1:19 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>>
>> On Tue, Oct 2, 2018 at 7:49 AM, Eric Dumazet <edumazet@google.com> wrote:
>>
>>
>> Does inet_frag_kill() hold fq->lock? I am missing how inet_frag_kill()
>> and inet_frags_exit_net() are synchronized.
>> Since you use smp_store_release()/READ_ONCE() they seem to run in
>> parallel. But then isn't it possible that inet_frag_kill() reads
>> nf->dead == 0, then inet_frags_exit_net() sets nf->dead, and then we
>> have the same race on concurrent removal? Or, isn't it possible that
>> inet_frag_kill() reads nf->dead == 1, but does not set
>> INET_FRAG_HASH_DEAD yet, and then inet_frags_free_cb() misses the
>> INET_FRAG_HASH_DEAD flag?
>>
>
> Yes this is kind of implied in my patch.
> I put the smp_store_release() and READ_ONCE exactly to document the
> possible races.
> This was the reason for my attempt in V1, doing a walk, but Herbert
> said walk was not designed for doing deletes.
>
> Proper synch will need a synchronize_rcu(), and thus a future
> conversion in net-next because we can not really
> add new synchronize_rcu() calls in an (struct
> pernet_operations.)exit() without considerable performance hit of
> netns dismantles.
>
> So this will require a conversion of all inet_frags_exit_net() callers
> to .exit_batch() to mitigate the cost.
>
> I thought of synchronize_rcu_bh() but this beast is going away soon anyway.
But if this patch allows all the same races and corruptions, then
what's the point?
^ permalink raw reply
* Re: [PATCH v2 net] inet: frags: rework rhashtable dismantle
From: Eric Dumazet @ 2018-10-02 14:04 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: David Miller, netdev, Eric Dumazet, Thomas Graf, Herbert Xu
In-Reply-To: <CACT4Y+aQDyzyK60SBDWWKQWBA99zpTW7Q-CofRpj7PX5cdqdmw@mail.gmail.com>
On Tue, Oct 2, 2018 at 6:46 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Oct 2, 2018 at 3:16 PM, Eric Dumazet <edumazet@google.com> wrote:
> > On Tue, Oct 2, 2018 at 1:19 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >>
> >> On Tue, Oct 2, 2018 at 7:49 AM, Eric Dumazet <edumazet@google.com> wrote:
> >>
> >>
> >> Does inet_frag_kill() hold fq->lock? I am missing how inet_frag_kill()
> >> and inet_frags_exit_net() are synchronized.
> >> Since you use smp_store_release()/READ_ONCE() they seem to run in
> >> parallel. But then isn't it possible that inet_frag_kill() reads
> >> nf->dead == 0, then inet_frags_exit_net() sets nf->dead, and then we
> >> have the same race on concurrent removal? Or, isn't it possible that
> >> inet_frag_kill() reads nf->dead == 1, but does not set
> >> INET_FRAG_HASH_DEAD yet, and then inet_frags_free_cb() misses the
> >> INET_FRAG_HASH_DEAD flag?
> >>
> >
> > Yes this is kind of implied in my patch.
> > I put the smp_store_release() and READ_ONCE exactly to document the
> > possible races.
> > This was the reason for my attempt in V1, doing a walk, but Herbert
> > said walk was not designed for doing deletes.
> >
> > Proper synch will need a synchronize_rcu(), and thus a future
> > conversion in net-next because we can not really
> > add new synchronize_rcu() calls in an (struct
> > pernet_operations.)exit() without considerable performance hit of
> > netns dismantles.
> >
> > So this will require a conversion of all inet_frags_exit_net() callers
> > to .exit_batch() to mitigate the cost.
> >
> > I thought of synchronize_rcu_bh() but this beast is going away soon anyway.
>
> But if this patch allows all the same races and corruptions, then
> what's the point?
Not really. The current races can last dozen of seconds, if youu have
one million frags.
With the fix, the race is in the order of one usec on typical hosts.
^ permalink raw reply
* Re: [PATCH v6] selftests: add headers_install to lib.mk
From: Michael Ellerman @ 2018-10-02 14:12 UTC (permalink / raw)
To: Shuah Khan, Anders Roxell, yamada.masahiro, michal.lkml, bamv2005,
brgl, pbonzini, akpm, rppt, aarcange
Cc: linux-kbuild, linux-kernel, linux-kselftest, netdev, linuxppc-dev,
Shuah Khan
In-Reply-To: <4473d2b6-a760-1a48-68e7-9f90023b57b5@kernel.org>
Shuah Khan <shuah@kernel.org> writes:
> On 09/27/2018 10:52 PM, Michael Ellerman wrote:
>> [ + linuxppc-dev ]
>>
>> Anders Roxell <anders.roxell@linaro.org> writes:
>>> If the kernel headers aren't installed we can't build all the tests.
>>> Add a new make target rule 'khdr' in the file lib.mk to generate the
>>> kernel headers and that gets include for every test-dir Makefile that
>>> includes lib.mk If the testdir in turn have its own sub-dirs the
>>> top_srcdir needs to be set to the linux-rootdir to be able to generate
>>> the kernel headers.
>>>
>>> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
>>> Reviewed-by: Fathi Boudra <fathi.boudra@linaro.org>
>>> ---
>>>
>>> I sent this (v5) a month ago and wondered if it got lost. Resending
>>> unchanged.
>>>
>>> Cheers,
>>> Anders
>>>
>>> Makefile | 14 +-------------
>>> scripts/subarch.include | 13 +++++++++++++
>>> tools/testing/selftests/android/Makefile | 2 +-
>>> tools/testing/selftests/android/ion/Makefile | 2 ++
>>> tools/testing/selftests/futex/functional/Makefile | 1 +
>>> tools/testing/selftests/gpio/Makefile | 7 ++-----
>>> tools/testing/selftests/kvm/Makefile | 7 ++-----
>>> tools/testing/selftests/lib.mk | 12 ++++++++++++
>>> tools/testing/selftests/net/Makefile | 1 +
>>> .../selftests/networking/timestamping/Makefile | 1 +
>>> tools/testing/selftests/vm/Makefile | 4 ----
>>> 11 files changed, 36 insertions(+), 28 deletions(-)
>>> create mode 100644 scripts/subarch.include
>>
>> This broke all the powerpc selftests :(
>
> Sorry for thr breakage.
>
>> Why did it go in at rc5?
>
> This patch has been in linux-next for a sometime before I decided to send this.
> My original intent was to send this for rc2, and my schedule was messed up with
> traveling. Since I didn't hear any issues from linux-next soaking, I made a call
> on sending this in for rc5.
OK. And I didn't notice the breakage in linux-next because _I_ was
travelling :)
> On second thought I should have waited until 4.20. Sorry about that.
Yeah that would have been better, no worries.
cheers
^ permalink raw reply
* [PATCH] SUNRPC: use cmpxchg64() in gss_seq_send64_fetch_and_inc()
From: Arnd Bergmann @ 2018-10-02 20:57 UTC (permalink / raw)
To: Trond Myklebust
Cc: Arnd Bergmann, Anna Schumaker, J. Bruce Fields, Jeff Layton,
David S. Miller, Stephen Hemminger, James Ettle, linux-nfs,
netdev, linux-kernel
The newly introduced gss_seq_send64_fetch_and_inc() fails to build on
32-bit architectures:
net/sunrpc/auth_gss/gss_krb5_seal.c:144:14: note: in expansion of macro 'cmpxchg'
seq_send = cmpxchg(&ctx->seq_send64, old, old + 1);
^~~~~~~
arch/x86/include/asm/cmpxchg.h:128:3: error: call to '__cmpxchg_wrong_size' declared with attribute error: Bad argument size for cmpxchg
__cmpxchg_wrong_size(); \
As the message tells us, cmpxchg() cannot be used on 64-bit arguments,
that's what cmpxchg64() does.
Fixes: 571ed1fd2390 ("SUNRPC: Replace krb5_seq_lock with a lockless scheme")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/sunrpc/auth_gss/gss_krb5_seal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sunrpc/auth_gss/gss_krb5_seal.c b/net/sunrpc/auth_gss/gss_krb5_seal.c
index 92594681d619..5775b9805bdc 100644
--- a/net/sunrpc/auth_gss/gss_krb5_seal.c
+++ b/net/sunrpc/auth_gss/gss_krb5_seal.c
@@ -141,7 +141,7 @@ gss_seq_send64_fetch_and_inc(struct krb5_ctx *ctx)
do {
old = seq_send;
- seq_send = cmpxchg(&ctx->seq_send64, old, old + 1);
+ seq_send = cmpxchg64(&ctx->seq_send64, old, old + 1);
} while (old != seq_send);
return seq_send;
}
--
2.18.0
^ permalink raw reply related
* [PATCH] XXX PCI/AER: remove unused variables
From: Arnd Bergmann @ 2018-10-02 21:02 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Arnd Bergmann, Oza Pawandeep, Jeff Kirsher, David S. Miller,
Solarflare linux maintainers, Edward Cree, Jacob Keller,
Amritha Nambiar, Alan Brady, Alexander Duyck, Shannon Nelson,
Jesper Dangaard Brouer, dmaengine, linux-kernel, intel-wired-lan,
netdev
A couple of files now contain a function with a return
code variable that is no longer used:
drivers/net/ethernet/sfc/efx.c: In function 'efx_io_slot_reset':
drivers/net/ethernet/sfc/efx.c:3824:6: error: unused variable 'rc' [-Werror=unused-variable]
int rc;
^~
drivers/net/ethernet/sfc/falcon/efx.c: In function 'ef4_io_slot_reset':
Oza Pawandeep <poza@codeaurora.org>
drivers/net/ethernet/sfc/falcon/efx.c:3163:6: error: unused variable 'rc' [-Werror=unused-variable]
int rc;
^~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function 'ixgbe_io_slot_reset':
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:11143:6: error: unused variable 'err' [-Werror=unused-variable]
int err;
^~~
drivers/net/ethernet/intel/i40e/i40e_main.c: In function 'i40e_pci_error_slot_reset':
drivers/net/ethernet/intel/i40e/i40e_main.c:14555:6: error: unused variable 'err' [-Werror=unused-variable]
int err;
drivers/dma/ioat/init.c: In function 'ioat_pcie_error_slot_reset':
drivers/dma/ioat/init.c:1255:6: error: unused variable 'err' [-Werror=unused-variable]
int err;
This removes all the ones I found during randconfig build testing.
Fixes: 6dcde3e574b2 ("XXX PCI/AER: Remove pci_cleanup_aer_uncorrect_error_status() calls")
Cc: Oza Pawandeep <poza@codeaurora.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/dma/ioat/init.c | 1 -
drivers/net/ethernet/intel/i40e/i40e_main.c | 1 -
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 1 -
drivers/net/ethernet/sfc/efx.c | 1 -
drivers/net/ethernet/sfc/falcon/efx.c | 1 -
5 files changed, 5 deletions(-)
diff --git a/drivers/dma/ioat/init.c b/drivers/dma/ioat/init.c
index 80c475fb8ede..bd8db5c99597 100644
--- a/drivers/dma/ioat/init.c
+++ b/drivers/dma/ioat/init.c
@@ -1252,7 +1252,6 @@ static pci_ers_result_t ioat_pcie_error_detected(struct pci_dev *pdev,
static pci_ers_result_t ioat_pcie_error_slot_reset(struct pci_dev *pdev)
{
pci_ers_result_t result = PCI_ERS_RESULT_RECOVERED;
- int err;
dev_dbg(&pdev->dev, "%s post reset handling\n", DRV_NAME);
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 4654ac69dfb6..bc71a21c1dc2 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -14552,7 +14552,6 @@ static pci_ers_result_t i40e_pci_error_slot_reset(struct pci_dev *pdev)
{
struct i40e_pf *pf = pci_get_drvdata(pdev);
pci_ers_result_t result;
- int err;
u32 reg;
dev_dbg(&pdev->dev, "%s\n", __func__);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 9bee51d900ac..0a2b9cad4b1c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -11140,7 +11140,6 @@ static pci_ers_result_t ixgbe_io_slot_reset(struct pci_dev *pdev)
{
struct ixgbe_adapter *adapter = pci_get_drvdata(pdev);
pci_ers_result_t result;
- int err;
if (pci_enable_device_mem(pdev)) {
e_err(probe, "Cannot re-enable PCI device after reset.\n");
diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index ec941ca967b3..98fe7e762e17 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -3821,7 +3821,6 @@ static pci_ers_result_t efx_io_slot_reset(struct pci_dev *pdev)
{
struct efx_nic *efx = pci_get_drvdata(pdev);
pci_ers_result_t status = PCI_ERS_RESULT_RECOVERED;
- int rc;
if (pci_enable_device(pdev)) {
netif_err(efx, hw, efx->net_dev,
diff --git a/drivers/net/ethernet/sfc/falcon/efx.c b/drivers/net/ethernet/sfc/falcon/efx.c
index 9b728efd71a4..8b1f94d7a6c5 100644
--- a/drivers/net/ethernet/sfc/falcon/efx.c
+++ b/drivers/net/ethernet/sfc/falcon/efx.c
@@ -3160,7 +3160,6 @@ static pci_ers_result_t ef4_io_slot_reset(struct pci_dev *pdev)
{
struct ef4_nic *efx = pci_get_drvdata(pdev);
pci_ers_result_t status = PCI_ERS_RESULT_RECOVERED;
- int rc;
if (pci_enable_device(pdev)) {
netif_err(efx, hw, efx->net_dev,
--
2.18.0
^ permalink raw reply related
* Re: [PATCH v2 net] inet: frags: rework rhashtable dismantle
From: Dmitry Vyukov @ 2018-10-02 14:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Eric Dumazet, Thomas Graf, Herbert Xu
In-Reply-To: <CANn89iJtt-=mvfGZPjRvZ4Y-HcoJtp3vSNZ=kEW4J_V7d1mpwg@mail.gmail.com>
On Tue, Oct 2, 2018 at 4:04 PM, Eric Dumazet <edumazet@google.com> wrote:
> On Tue, Oct 2, 2018 at 6:46 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>>
>> On Tue, Oct 2, 2018 at 3:16 PM, Eric Dumazet <edumazet@google.com> wrote:
>> > On Tue, Oct 2, 2018 at 1:19 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>> >>
>> >> On Tue, Oct 2, 2018 at 7:49 AM, Eric Dumazet <edumazet@google.com> wrote:
>> >>
>> >>
>> >> Does inet_frag_kill() hold fq->lock? I am missing how inet_frag_kill()
>> >> and inet_frags_exit_net() are synchronized.
>> >> Since you use smp_store_release()/READ_ONCE() they seem to run in
>> >> parallel. But then isn't it possible that inet_frag_kill() reads
>> >> nf->dead == 0, then inet_frags_exit_net() sets nf->dead, and then we
>> >> have the same race on concurrent removal? Or, isn't it possible that
>> >> inet_frag_kill() reads nf->dead == 1, but does not set
>> >> INET_FRAG_HASH_DEAD yet, and then inet_frags_free_cb() misses the
>> >> INET_FRAG_HASH_DEAD flag?
>> >>
>> >
>> > Yes this is kind of implied in my patch.
>> > I put the smp_store_release() and READ_ONCE exactly to document the
>> > possible races.
>> > This was the reason for my attempt in V1, doing a walk, but Herbert
>> > said walk was not designed for doing deletes.
>> >
>> > Proper synch will need a synchronize_rcu(), and thus a future
>> > conversion in net-next because we can not really
>> > add new synchronize_rcu() calls in an (struct
>> > pernet_operations.)exit() without considerable performance hit of
>> > netns dismantles.
>> >
>> > So this will require a conversion of all inet_frags_exit_net() callers
>> > to .exit_batch() to mitigate the cost.
>> >
>> > I thought of synchronize_rcu_bh() but this beast is going away soon anyway.
>>
>> But if this patch allows all the same races and corruptions, then
>> what's the point?
>
> Not really. The current races can last dozen of seconds, if youu have
> one million frags.
>
> With the fix, the race is in the order of one usec on typical hosts.
Ah, I see. A known bug probably worth a comment in the code.
^ permalink raw reply
* Re: [PATCH v2 net] inet: frags: rework rhashtable dismantle
From: Eric Dumazet @ 2018-10-02 14:32 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: David Miller, netdev, Eric Dumazet, Thomas Graf, Herbert Xu
In-Reply-To: <CACT4Y+b570jQnJjARfOcUeyyb8RTSUGP5ZeOXQGr3Hmt9OhFWw@mail.gmail.com>
On Tue, Oct 2, 2018 at 7:28 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Oct 2, 2018 at 4:04 PM, Eric Dumazet <edumazet@google.com> wrote:
> > On Tue, Oct 2, 2018 at 6:46 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >>
> >> On Tue, Oct 2, 2018 at 3:16 PM, Eric Dumazet <edumazet@google.com> wrote:
> >> > On Tue, Oct 2, 2018 at 1:19 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >> >>
> >> >> On Tue, Oct 2, 2018 at 7:49 AM, Eric Dumazet <edumazet@google.com> wrote:
> >> >>
> >> >>
> >> >> Does inet_frag_kill() hold fq->lock? I am missing how inet_frag_kill()
> >> >> and inet_frags_exit_net() are synchronized.
> >> >> Since you use smp_store_release()/READ_ONCE() they seem to run in
> >> >> parallel. But then isn't it possible that inet_frag_kill() reads
> >> >> nf->dead == 0, then inet_frags_exit_net() sets nf->dead, and then we
> >> >> have the same race on concurrent removal? Or, isn't it possible that
> >> >> inet_frag_kill() reads nf->dead == 1, but does not set
> >> >> INET_FRAG_HASH_DEAD yet, and then inet_frags_free_cb() misses the
> >> >> INET_FRAG_HASH_DEAD flag?
> >> >>
> >> >
> >> > Yes this is kind of implied in my patch.
> >> > I put the smp_store_release() and READ_ONCE exactly to document the
> >> > possible races.
> >> > This was the reason for my attempt in V1, doing a walk, but Herbert
> >> > said walk was not designed for doing deletes.
> >> >
> >> > Proper synch will need a synchronize_rcu(), and thus a future
> >> > conversion in net-next because we can not really
> >> > add new synchronize_rcu() calls in an (struct
> >> > pernet_operations.)exit() without considerable performance hit of
> >> > netns dismantles.
> >> >
> >> > So this will require a conversion of all inet_frags_exit_net() callers
> >> > to .exit_batch() to mitigate the cost.
> >> >
> >> > I thought of synchronize_rcu_bh() but this beast is going away soon anyway.
> >>
> >> But if this patch allows all the same races and corruptions, then
> >> what's the point?
> >
> > Not really. The current races can last dozen of seconds, if youu have
> > one million frags.
> >
> > With the fix, the race is in the order of one usec on typical hosts.
>
> Ah, I see. A known bug probably worth a comment in the code.
Plan is to use proper synchronize_rcu() in net-next
For net tree, I prefer not having to deal with backports hassle since
netns dismantles got many changes last 6 months.
^ permalink raw reply
* Re: [PATCH] team: set IFF_SLAVE on team ports
From: Chas Williams @ 2018-10-02 21:20 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Stephen Hemminger, Jan Blunck, LKML, netdev
In-Reply-To: <20181002111215.GA2222@nanopsycho>
On 10/02/18 07:12, Jiri Pirko wrote:
> Mon, Oct 01, 2018 at 04:06:16PM CEST, 3chas3@gmail.com wrote:
>>
>>
>> On 09/30/18 05:34, Jiri Pirko wrote:
>>> Sun, Sep 30, 2018 at 11:38:05AM CEST, stephen@networkplumber.org wrote:
>>>> On Sun, 30 Sep 2018 09:14:14 +0200
>>>> Jiri Pirko <jiri@resnulli.us> wrote:
>>>>
>>>>> Thu, Sep 27, 2018 at 04:04:26PM CEST, 3chas3@gmail.com wrote:
>>>>>>
>>>>>>
>>>>>> On 07/10/15 02:41, Jiri Pirko wrote:
>>>>>>> Thu, Jul 09, 2015 at 05:36:55PM CEST, jblunck@infradead.org wrote:
>>>>>>>> On Thu, Jul 9, 2015 at 12:07 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>>>>>>> Thu, Jul 09, 2015 at 11:58:34AM CEST, jblunck@infradead.org wrote:
>>>>>>>>>> The code in net/ipv6/addrconf.c:addrconf_notify() tests for IFF_SLAVE to
>>>>>>>>>> decide if it should start the address configuration. Since team ports
>>>>>>>>>> shouldn't get link-local addresses assigned lets set IFF_SLAVE when linking
>>>>>>>>>> a port to the team master.
>>>>>>>>>
>>>>>>>>> I don't want to use IFF_SLAVE in team. Other master-slave devices are
>>>>>>>>> not using that as well, for example bridge, ovs, etc.
>>>>>>>>
>>>>>>>> Maybe they need to get fixed too. I've used that flag because it is
>>>>>>>> documented as
>>>>>>>> a "slave of a load balancer" which describes what a team port is.
>>>>>>>>
>>>>>>>>> I think that this should be fixed in addrconf_notify. It should lookup
>>>>>>>>> if there is a master on top and bail out in that case.
>>>>>>>>
>>>>>>>> There are other virtual interfaces that have a master assigned and want to
>>>>>>>> participate in IPv6 address configuration.
>>>>>>>
>>>>>>> Can you give me an example?
>>>>>>
>>>>>> I would like to revisit this patch (yes, I know it has been a while). I
>>>>>> believe the VRF implementation uses master to group the interfaces under
>>>>>> a single interface.
>>>>>>
>>>>>> I don't see a reason not to use IFF_SLAVE since team and bonding are fairly
>>>>>> similar.
>>>>>
>>>>> Again, why do you need team port to have IFF_SLAVE flag? What do you
>>>>> want to achieve
>>>>
>>>> Without setting this flag IPv6 will try and make a link specific address.
>
> You are talking about addrconf_notify() right? Easy to fix to check
> something more convenient. Like netif_is_lag_port() if you want to avoid
> it for bond/team. netif_is_ovs_port(), netif_is_bridge_port() etc. Lot's
> of helpers to cover this.
OK, IPv6 should probably be using this.
>
>
>
>>>
>>> Why is it not an issue with bridge, ovs, and other master-slave devices?
>>>
>>
>> It very well might be an issue for bridge and ovs. Other master-slave
>> devices include the existing VRF implementation in the kernel and those slave
>> interfaces will certainly want to use IPv6.
>>
>> However, IFF_SLAVE has a specific meaning:
>>
>> ./include/uapi/linux/if.h: * @IFF_SLAVE: slave of a load balancer. Volatile.
>
> I know that some userspace apps are using this flag to determine a
> "bonding slave". I don't think that they care much about eql...
>
>
>>
>> The bonding driver is not the only user:
>>
>> ./drivers/net/eql.c:#define eql_is_slave(dev) ((dev->flags & IFF_SLAVE) ==
>> IFF_SLAVE)
>> ./drivers/net/eql.c: slave->dev->flags &= ~IFF_SLAVE;
>> ./drivers/net/eql.c: slave->dev->flags |= IFF_SLAVE;
>>
>> The team driver would like to use this same flag since it is a load balancer
>> as well. The side effect of not assigning IPv6 is a bonus. The fact that
>
> No, please leave IFF_SLAVE as it is. Both kernel and userspace have
> their clear indications right now about the master/slave relationships.
The team driver does create a master/slave relationship. The team
slaves are literally slaves of the master device. It's not clear to me
why you we can't mark the slaves of the team master as actually being
slave interfaces?
>
>
>> bridges and ovs are also likely broken is a different issue. Should there be
>> a another flag that says "layer 2 only"? Very possibly, but that is
>> something all these interfaces should be using to include bonding, team, eql,
>> obs, bridge etc. That's not a reasonable objection to labeling the team
>> slave as slaves since they are literally slaves of a load balancer.
>>
>>
>>
^ permalink raw reply
* Re: [PATCH net] rtnetlink: Fail dump if target netnsid is invalid
From: David Ahern @ 2018-10-02 14:41 UTC (permalink / raw)
To: Jiri Benc, David Ahern; +Cc: netdev, davem
In-Reply-To: <20181002120431.0817f48e@redhat.com>
On 10/2/18 4:04 AM, Jiri Benc wrote:
> On Fri, 28 Sep 2018 12:28:41 -0700, David Ahern wrote:
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
>> @@ -1898,10 +1898,8 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
>> if (tb[IFLA_IF_NETNSID]) {
>> netnsid = nla_get_s32(tb[IFLA_IF_NETNSID]);
>> tgt_net = get_target_net(skb->sk, netnsid);
>> - if (IS_ERR(tgt_net)) {
>> - tgt_net = net;
>> - netnsid = -1;
>> - }
>> + if (IS_ERR(tgt_net))
>> + return PTR_ERR(tgt_net);
>> }
>>
>> if (tb[IFLA_EXT_MASK])
>
> Sorry for the late review, I see it has been applied.
>
> I intentionally chose the behavior to preserve the behavior of the
> older kernels: that attribute was silently ignored. Note that the
> IFLA_IF_NETNSID is not returned in such case, thus it's easy to
> distinguish that it was not applied. And the user space has to do such
> check anyway to support old kernels.
First, rtnl_dellink, rtnl_newlink and rtnl_getlink all fail if net
namespace id is invalid. Second, the user is requesting data from a
target namespace and the dump happily continued with the current
namespace which is not what the user requested. Hence, it makes no sense
for a dump to continue which is why I sent the patch.
>
> But you're right that there was no way to distinguish "the kernel does
> not support IFLA_IF_NETNSID" from "wrong IFLA_IF_NETNSID provided". I'm
> okay with the patch, I just don't think the "Fixes" tag is justified but
> whatever, can't be unapplied :-) (and it's my fault for not reviewing
> the patches timely).
The id was the commit that added the code to ignore the error.
^ permalink raw reply
* Re: [PATCH v3] PCI: Reprogram bridge prefetch registers on resume
From: Thomas Martitz @ 2018-10-02 21:26 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: andy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ, Linux PM,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Wysocki, Rafael J,
Linux Kernel, Daniel Drake, Keith Busch, netdev, Linux PCI,
rchang-eYqpPyKDWXRBDgjK7y7TUQ, Linux Upstreaming Team,
David Miller, Jon Derrick, Heiner Kallweit
In-Reply-To: <20181002200350.GC120535-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
Am 02.10.18 um 22:03 schrieb Bjorn Helgaas:
> Hi Thomas,
>
> On Mon, Oct 01, 2018 at 04:25:06PM +0200, Thomas Martitz wrote:
>> Am 01.10.18 um 06:57 schrieb Daniel Drake:
>>> On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz <kugel@rockbox.org> wrote:
>>>> The latest iteration does not work on my HP system. The GPU fails to
>>>> power up just like the unpatched kernel.
>>>
>>> That's weird, I would not expect a behaviour change in the latest
>>> patch. pci_restore_config_dword() has some debug messages, could you
>>> please make them visible and show logs again?
>>> Also remind us of the PCI device address of the parent bridge (lspci -vt)
>>
>> I'll follow up with more the requested information on bugzilla
>> (Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069).
>>
>> On a quick re-check, it seems to depend on if I used the eGPU before
>> the initial suspend. If I run glxgears (with DRI_PRIME=1) before suspend it
>> seems fine.
>
> Does the patch ([1]) make things *worse* compared to v4.19-rc5?
>
No, certainly not. It does look like a different issue since resuming now
works at least if I used the eGPU in some way before suspend
(DRI_PRIME=1 glxgears seems to be enough, I assume glxinfo would work as
well).
Without the patch resuming the eGPU does not work whatsoever.
Please ship the patch. I'll hopefully sort this other issue out.
Best regards.
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* Re: [PATCH] XXX PCI/AER: remove unused variables
From: Bjorn Helgaas @ 2018-10-02 21:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: poza, Kirsher, Jeffrey T, David Miller, linux-net-drivers,
Edward Cree, Jacob Keller, amritha.nambiar, alan.brady,
Alex Duyck, shannon.nelson, brouer, dmaengine,
Linux Kernel Mailing List, intel-wired-lan, netdev
In-Reply-To: <20181002210426.2447078-1-arnd@arndb.de>
On Tue, Oct 2, 2018 at 4:04 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> A couple of files now contain a function with a return
> code variable that is no longer used:
These are fixed already, thanks.
> drivers/net/ethernet/sfc/efx.c: In function 'efx_io_slot_reset':
> drivers/net/ethernet/sfc/efx.c:3824:6: error: unused variable 'rc' [-Werror=unused-variable]
> int rc;
> ^~
> drivers/net/ethernet/sfc/falcon/efx.c: In function 'ef4_io_slot_reset':
> Oza Pawandeep <poza@codeaurora.org>
> drivers/net/ethernet/sfc/falcon/efx.c:3163:6: error: unused variable 'rc' [-Werror=unused-variable]
> int rc;
> ^~
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function 'ixgbe_io_slot_reset':
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:11143:6: error: unused variable 'err' [-Werror=unused-variable]
> int err;
> ^~~
> drivers/net/ethernet/intel/i40e/i40e_main.c: In function 'i40e_pci_error_slot_reset':
> drivers/net/ethernet/intel/i40e/i40e_main.c:14555:6: error: unused variable 'err' [-Werror=unused-variable]
> int err;
>
> drivers/dma/ioat/init.c: In function 'ioat_pcie_error_slot_reset':
> drivers/dma/ioat/init.c:1255:6: error: unused variable 'err' [-Werror=unused-variable]
> int err;
>
> This removes all the ones I found during randconfig build testing.
>
> Fixes: 6dcde3e574b2 ("XXX PCI/AER: Remove pci_cleanup_aer_uncorrect_error_status() calls")
> Cc: Oza Pawandeep <poza@codeaurora.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/dma/ioat/init.c | 1 -
> drivers/net/ethernet/intel/i40e/i40e_main.c | 1 -
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 1 -
> drivers/net/ethernet/sfc/efx.c | 1 -
> drivers/net/ethernet/sfc/falcon/efx.c | 1 -
> 5 files changed, 5 deletions(-)
>
> diff --git a/drivers/dma/ioat/init.c b/drivers/dma/ioat/init.c
> index 80c475fb8ede..bd8db5c99597 100644
> --- a/drivers/dma/ioat/init.c
> +++ b/drivers/dma/ioat/init.c
> @@ -1252,7 +1252,6 @@ static pci_ers_result_t ioat_pcie_error_detected(struct pci_dev *pdev,
> static pci_ers_result_t ioat_pcie_error_slot_reset(struct pci_dev *pdev)
> {
> pci_ers_result_t result = PCI_ERS_RESULT_RECOVERED;
> - int err;
>
> dev_dbg(&pdev->dev, "%s post reset handling\n", DRV_NAME);
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index 4654ac69dfb6..bc71a21c1dc2 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -14552,7 +14552,6 @@ static pci_ers_result_t i40e_pci_error_slot_reset(struct pci_dev *pdev)
> {
> struct i40e_pf *pf = pci_get_drvdata(pdev);
> pci_ers_result_t result;
> - int err;
> u32 reg;
>
> dev_dbg(&pdev->dev, "%s\n", __func__);
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 9bee51d900ac..0a2b9cad4b1c 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -11140,7 +11140,6 @@ static pci_ers_result_t ixgbe_io_slot_reset(struct pci_dev *pdev)
> {
> struct ixgbe_adapter *adapter = pci_get_drvdata(pdev);
> pci_ers_result_t result;
> - int err;
>
> if (pci_enable_device_mem(pdev)) {
> e_err(probe, "Cannot re-enable PCI device after reset.\n");
> diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
> index ec941ca967b3..98fe7e762e17 100644
> --- a/drivers/net/ethernet/sfc/efx.c
> +++ b/drivers/net/ethernet/sfc/efx.c
> @@ -3821,7 +3821,6 @@ static pci_ers_result_t efx_io_slot_reset(struct pci_dev *pdev)
> {
> struct efx_nic *efx = pci_get_drvdata(pdev);
> pci_ers_result_t status = PCI_ERS_RESULT_RECOVERED;
> - int rc;
>
> if (pci_enable_device(pdev)) {
> netif_err(efx, hw, efx->net_dev,
> diff --git a/drivers/net/ethernet/sfc/falcon/efx.c b/drivers/net/ethernet/sfc/falcon/efx.c
> index 9b728efd71a4..8b1f94d7a6c5 100644
> --- a/drivers/net/ethernet/sfc/falcon/efx.c
> +++ b/drivers/net/ethernet/sfc/falcon/efx.c
> @@ -3160,7 +3160,6 @@ static pci_ers_result_t ef4_io_slot_reset(struct pci_dev *pdev)
> {
> struct ef4_nic *efx = pci_get_drvdata(pdev);
> pci_ers_result_t status = PCI_ERS_RESULT_RECOVERED;
> - int rc;
>
> if (pci_enable_device(pdev)) {
> netif_err(efx, hw, efx->net_dev,
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH net-next v6 19/23] zinc: Curve25519 ARM implementation
From: Richard Weinberger @ 2018-10-02 21:35 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Jason A. Donenfeld, LKML, netdev, linux-crypto, David S. Miller,
Greg KH, sneves, Andy Lutomirski, jeanphilippe.aumasson,
Russell King - ARM Linux, linux-arm-kernel
In-Reply-To: <CAKv+Gu9FLDRLxHReKcveZYHNYerR5Y2pZd9gn-hWrU0jb2KgfA@mail.gmail.com>
Ard,
On Tue, Oct 2, 2018 at 7:06 PM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> I guess qhasm means generated code, right?
Yes.
Please see: http://cr.yp.to/qhasm.html
It generates code from a q-file (the "template").
Actually it is a rather powerful tool, but as you noticed, sometimes
the code is not perfect.
--
Thanks,
//richard
^ permalink raw reply
* Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels
From: Florian Westphal @ 2018-10-02 21:35 UTC (permalink / raw)
To: Wolfgang Walter
Cc: Florian Westphal, Steffen Klassert, David Miller, netdev,
linux-kernel, torvalds, christophe.gouault
In-Reply-To: <4327972.7bla238zOs@stwm.de>
Wolfgang Walter <linux@stwm.de> wrote:
> Am Dienstag, 2. Oktober 2018, 16:56:16 schrieb Florian Westphal:
> > I'm experimenting with per-dst inexact lists in an rbtree but
> > this will take time.
>
> Hmm, I doubt that this is worth the effort. And certainly not that easy
Well, I'm not going to send a revert of the flowcache removal.
I'm willing to experiment with alternatives to a full iteration of the
inexact list but thats it.
> correctly done, as it still would have to obey the original order of the rules
> (their priority).
Except that neither the priority or the order in which it was added
matters in case the selector doesn't match.
I see no reason why we can't have inexact lists done per dst<->src pairs.
> You may have a lot of rules of the form say
>
> 10.0.0.0/16 <=> 10.1.0.0/29 encrypt ....
> 10.0.0.0/16 <=> 10.1.0.8/29 encrypt ....
Sure.
> Also, you get something like that
>
> 10.0.1.0/24 <=> 10.0.2.0/29 allow
> 10.0.0.0/16 <=> 10.0.2.0/24 encrypt
> 0.0.0.0 <=> 10.0.2.0/16 block
>
> And people may use source port and/or destination port or protocol
> (tcp/udp/imcp) to further tailor there ruleset.
Yes. 0.0.0.0/0 handling will require some extra consideration.
So far I have not seen a show-stopper however.
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 03/25] netlink: introduce NLM_F_DUMP_PROPER_HDR flag
From: David Ahern @ 2018-10-02 14:55 UTC (permalink / raw)
To: Jiri Benc, David Ahern; +Cc: netdev, davem, christian, stephen
In-Reply-To: <20181002130614.77856ff8@redhat.com>
On 10/2/18 5:06 AM, Jiri Benc wrote:
> On Mon, 1 Oct 2018 17:28:29 -0700, David Ahern wrote:
>> Add a new flag, NLM_F_DUMP_PROPER_HDR, for userspace to indicate to the
>> kernel that it believes it is sending the right header struct for the
>> dump message type (ifinfomsg, ifaddrmsg, rtmsg, fib_rule_hdr, ...).
>
> Why is this limited to dumps? Other kind of netlink messages contain
> the common struct, too. When introducing such mechanism, please make it
> generic.
Because all of the other requests -- NEW, DEL, and GET -- all seem to
use and expect the right header. Dumps are the ones where the header is
not looked at in most cases and for years iproute2 got away with sending
the wrong one.
>
> Last time when we were discussing strict checking in netlink, it was
> suggested to add a socket option instead of adding NLM flags[1].
> It makes a lot of sense: the number of flags is very limited and we'd
> run out of them pretty fast. It's not just the header structure that
> is currently checked sloppily. It's also attributes, flags in
> attributes, etc. We can't assign a flag to all of them.
>
> You should also consider a different name for the flag: it should
> reflect what the effect of the flag is. "Proper header" is not an
> effect, it's a requirement for the message to pass. The effect is
> enforced strict checking of the header.
Proper means the correct header for the dump type is sent.
You want take issue with a name suggest a different one.
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 03/25] netlink: introduce NLM_F_DUMP_PROPER_HDR flag
From: David Ahern @ 2018-10-02 14:57 UTC (permalink / raw)
To: Jiri Benc, Christian Brauner; +Cc: David Ahern, netdev, davem, stephen
In-Reply-To: <20181002132755.267a11fe@redhat.com>
On 10/2/18 5:27 AM, Jiri Benc wrote:
> On Tue, 2 Oct 2018 13:18:32 +0200, Christian Brauner wrote:
>> I didn't find this in the linked thread.
>
> Maybe it was suggested in another thread or in person on a conference,
> I can't remember, it's too long ago, sorry.
>
>> What I find interesting and convincing is one of Dave's points:
>>
>> "I'm beginning to wonder if we can just change this unilaterally to
>> not ignore unrecognized attributes.
>>
>> I am increasingly certain that things that would "break" we wouldn't
>> want to succeed anyways." [1]
>
> It's unfortunate we can't do that. I'd like it.
You can when you introduce a new option or a new flag that is required
to get new behavior like kernel side filtering.
>
>> But a socket option or this header flag both sound acceptable to me. Was
>> there any more detail on how a socket option would look like, i.e. an
>> api proposal or something?
>
> Look at how NETLINK_CAP_ACK and NETLINK_EXT_ACK is implemented.
I chose a netlink flag for consistency with NLM_F_DUMP_INTR and
NLM_F_DUMP_FILTERED. Both are netlink flags. This patch set fixes only
what is broken -- dumps.
^ permalink raw reply
* Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses
From: Nikolay Aleksandrov @ 2018-10-02 14:59 UTC (permalink / raw)
To: Richard Weinberger, Ido Schimmel
Cc: Stephen Hemminger, Florian Fainelli, bernhard.thaler,
David S. Miller, bridge, netdev, David Gstir, roopa
In-Reply-To: <16029249.TkoLblyBmC@blindfold>
On 01/10/2018 22:10, Richard Weinberger wrote:
> Am Montag, 1. Oktober 2018, 21:04:33 CEST schrieb Ido Schimmel:
>> On Mon, Oct 01, 2018 at 08:54:08PM +0200, Richard Weinberger wrote:
>>> So the only option is having a bridge and transport STP via tc-mirred
>>> or patching the bridge code (what we do right now).
>>
>> And I vote for the first option. I understand it involves more typing,
>
> hehe, it is not about typing. The setup is done by a script.
> And we both know that getting a patch upstream is much more work than
> typing a few lines of hacky bash scripts.
> Since I want a decent solution and feedback I'm bringing this up here.
>
> I could also just go with my in-house patch and don't tell anyone...
>
>> but I see no reason to push more complexity into the kernel - and break
>> standards - when you can relatively easily accomplish the same thing in
>> other ways.
>
> If having a bridge plus u32+mirred for STP bypass is the preferred solution,
> I'm fine with it.
> So far we use the kernel patch and didn't test the mirred-bypass a lot.
> My fear was that mirred rules from eth0 to eth1 and back might cause a
> loop or confuse the bridge...
>
>> Adding Nik and Roopa who now maintain the bridge code and should
>> eventually decide about this.
>
> Thanks,
> //richard
>
>
>
>
Richard please check commit:
commit 5af48b59f35c
Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Wed Sep 27 16:12:44 2017 +0300
net: bridge: add per-port group_fwd_mask with less restrictions
We need to be able to transparently forward most link-local frames via
tunnels (e.g. vxlan, qinq). Currently the bridge's group_fwd_mask has a
mask which restricts the forwarding of STP and LACP, but we need to be able
to forward these over tunnels and control that forwarding on a per-port
basis thus add a new per-port group_fwd_mask option which only disallows
mac pause frames to be forwarded (they're always dropped anyway).
The patch does not change the current default situation - all of the others
are still restricted unless configured for forwarding.
We have successfully tested this patch with LACP and STP forwarding over
VxLAN and qinq tunnels.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Will this work for you ?
It's in the bridge since v4.15.
Thanks,
Nik
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump to push inet6_fill_args to in6_dump_addrs
From: David Ahern @ 2018-10-02 15:11 UTC (permalink / raw)
To: Jiri Benc, David Ahern; +Cc: netdev, davem, christian, stephen
In-Reply-To: <20181002125425.35e96876@redhat.com>
On 10/2/18 4:54 AM, Jiri Benc wrote:
> On Mon, 1 Oct 2018 17:28:28 -0700, David Ahern wrote:
>> Pull the inet6_fill_args arg up to in6_dump_addrs and move netnsid
>> into it. Since IFA_TARGET_NETNSID is a kernel side filter add the
>> NLM_F_DUMP_FILTERED flag so userspace knows the request was honored.
>
> IFA_TARGET_NETNSID is not a filter.
>
> "Filter" returns a subset of the results. It's kind of optimization
> when one is interested only in some data but not all of them. Instead
> of dumping everything, going through the results and picking only the
> data one is interested in, it's better to pass a filter and get only
> the relevant data. But you're not really required to: you can filter in
> your app.
Generically speaking a filter modifies the output based on the input.
Specifying a target namespace is an input to the dump that modifies the
output.
Yes, you can do it in userspace which is what iproute2 has done to this
point, but it is grossly inefficient and that inefficiency has
implications at scale.
^ permalink raw reply
* [net-next 0/9][pull request] 100GbE Intel Wired LAN Driver Updates 2018-10-02
From: Jeff Kirsher @ 2018-10-02 15:24 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains updates to ice driver only.
Anirudh expands the use of VSI handles across the rest of the driver,
which includes refactoring the code to correctly use VSI handles. After
a reset, ensure that all configurations for a VSI get re-applied before
moving on to rebuilding the next VSI.
Dave fixed the driver to check the current link state after reset to
ensure that the correct link state of a port is reported. Fixed an
issue where if the driver is unloaded when traffic is in progress,
errors are generated.
Preethi breaks up the IRQ tracker into a software and hardware IRQ
tracker, where the software IRQ tracker tracks only the PF's IRQ
requests and does not play any role in the VF initialization. The
hardware IRQ tracker represents the device's interrupt space and will be
looked up to see if the device has run our of interrupts when a
interrupt has to be allocated in the device for either PF or VF.
Md Fahad adds support for enabling/disabling RSS via ethtool.
Brett aligns the ice_reset_req enum values to the values that the
hardware understands. Also added initial support for dynamic interrupt
moderation in the ice driver.
The following are changes since commit 024926def6ca95819442699fbecc1fe376253fb9:
net: phy: Convert to using %pOFn instead of device_node.name
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 100GbE
Anirudh Venkataramanan (3):
ice: Expand use of VSI handles part 1/2
ice: Expand use of VSI handles part 2/2
ice: Implement VSI replay framework
Brett Creeley (2):
ice: Align ice_reset_req enum values to hardware reset values
ice: Add support for dynamic interrupt moderation
Dave Ertman (2):
ice: Check for actual link state of port after reset
ice: Fix error on driver remove
Md Fahad Iqbal Polash (1):
ice: Implement ethtool hook for RSS switch
Preethi Banala (1):
ice: Split irq_tracker into sw_irq_tracker and hw_irq_tracker
drivers/net/ethernet/intel/ice/ice.h | 25 +-
drivers/net/ethernet/intel/ice/ice_common.c | 180 +++++-
drivers/net/ethernet/intel/ice/ice_common.h | 16 +-
.../net/ethernet/intel/ice/ice_hw_autogen.h | 5 +
drivers/net/ethernet/intel/ice/ice_lib.c | 182 ++++--
drivers/net/ethernet/intel/ice/ice_lib.h | 2 +
drivers/net/ethernet/intel/ice/ice_main.c | 209 +++++--
drivers/net/ethernet/intel/ice/ice_sched.c | 151 ++---
drivers/net/ethernet/intel/ice/ice_sched.h | 5 +-
drivers/net/ethernet/intel/ice/ice_switch.c | 573 +++++++++++-------
drivers/net/ethernet/intel/ice/ice_switch.h | 45 +-
drivers/net/ethernet/intel/ice/ice_txrx.h | 17 +-
drivers/net/ethernet/intel/ice/ice_type.h | 49 +-
13 files changed, 952 insertions(+), 507 deletions(-)
--
2.17.1
^ permalink raw reply
* [net-next 1/9] ice: Expand use of VSI handles part 1/2
From: Jeff Kirsher @ 2018-10-02 15:24 UTC (permalink / raw)
To: davem
Cc: Anirudh Venkataramanan, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20181002152447.11175-1-jeffrey.t.kirsher@intel.com>
From: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
A VSI handle is just a number the driver maintains to uniquely identify
a VSI. A VSI handle is backed by a VSI number in the hardware. When
interacting when the hardware, VSI handles are converted into VSI numbers.
In commit 0f9d5027a749 ("ice: Refactor VSI allocation, deletion and
rebuild flow"), VSI handles were introduced but it was used only
when creating and deleting VSIs. This patch is part one of two patches
that expands the use of VSI handles across the rest of the driver. Also
in this patch, certain parts of the code had to be refactored to correctly
use VSI handles.
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ice/ice_lib.c | 28 +-
drivers/net/ethernet/intel/ice/ice_main.c | 4 +-
drivers/net/ethernet/intel/ice/ice_switch.c | 462 ++++++++++++--------
drivers/net/ethernet/intel/ice/ice_switch.h | 34 +-
4 files changed, 328 insertions(+), 200 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
index 95588fe0e22f..b44ccdb56952 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
@@ -1290,10 +1290,10 @@ int ice_add_mac_to_list(struct ice_vsi *vsi, struct list_head *add_list,
return -ENOMEM;
tmp->fltr_info.flag = ICE_FLTR_TX;
- tmp->fltr_info.src = vsi->vsi_num;
+ tmp->fltr_info.src_id = ICE_SRC_ID_VSI;
tmp->fltr_info.lkup_type = ICE_SW_LKUP_MAC;
tmp->fltr_info.fltr_act = ICE_FWD_TO_VSI;
- tmp->fltr_info.fwd_id.vsi_id = vsi->vsi_num;
+ tmp->fltr_info.vsi_handle = vsi->idx;
ether_addr_copy(tmp->fltr_info.l_data.mac.mac_addr, macaddr);
INIT_LIST_HEAD(&tmp->list_entry);
@@ -1394,8 +1394,8 @@ int ice_vsi_add_vlan(struct ice_vsi *vsi, u16 vid)
tmp->fltr_info.lkup_type = ICE_SW_LKUP_VLAN;
tmp->fltr_info.fltr_act = ICE_FWD_TO_VSI;
tmp->fltr_info.flag = ICE_FLTR_TX;
- tmp->fltr_info.src = vsi->vsi_num;
- tmp->fltr_info.fwd_id.vsi_id = vsi->vsi_num;
+ tmp->fltr_info.src_id = ICE_SRC_ID_VSI;
+ tmp->fltr_info.vsi_handle = vsi->idx;
tmp->fltr_info.l_data.vlan.vlan_id = vid;
INIT_LIST_HEAD(&tmp->list_entry);
@@ -1431,11 +1431,11 @@ int ice_vsi_kill_vlan(struct ice_vsi *vsi, u16 vid)
return -ENOMEM;
list->fltr_info.lkup_type = ICE_SW_LKUP_VLAN;
- list->fltr_info.fwd_id.vsi_id = vsi->vsi_num;
+ list->fltr_info.vsi_handle = vsi->idx;
list->fltr_info.fltr_act = ICE_FWD_TO_VSI;
list->fltr_info.l_data.vlan.vlan_id = vid;
list->fltr_info.flag = ICE_FLTR_TX;
- list->fltr_info.src = vsi->vsi_num;
+ list->fltr_info.src_id = ICE_SRC_ID_VSI;
INIT_LIST_HEAD(&list->list_entry);
list_add(&list->list_entry, &tmp_add_list);
@@ -1636,9 +1636,8 @@ int ice_vsi_manage_vlan_insertion(struct ice_vsi *vsi)
ctxt.info.vlan_flags = ICE_AQ_VSI_VLAN_MODE_ALL;
ctxt.info.valid_sections = cpu_to_le16(ICE_AQ_VSI_PROP_VLAN_VALID);
- ctxt.vsi_num = vsi->vsi_num;
- status = ice_aq_update_vsi(hw, &ctxt, NULL);
+ status = ice_update_vsi(hw, vsi->idx, &ctxt, NULL);
if (status) {
dev_err(dev, "update VSI for VLAN insert failed, err %d aq_err %d\n",
status, hw->adminq.sq_last_status);
@@ -1677,9 +1676,8 @@ int ice_vsi_manage_vlan_stripping(struct ice_vsi *vsi, bool ena)
ctxt.info.vlan_flags |= ICE_AQ_VSI_VLAN_MODE_ALL;
ctxt.info.valid_sections = cpu_to_le16(ICE_AQ_VSI_PROP_VLAN_VALID);
- ctxt.vsi_num = vsi->vsi_num;
- status = ice_aq_update_vsi(hw, &ctxt, NULL);
+ status = ice_update_vsi(hw, vsi->idx, &ctxt, NULL);
if (status) {
dev_err(dev, "update VSI for VLAN strip failed, ena = %d err %d aq_err %d\n",
ena, status, hw->adminq.sq_last_status);
@@ -1829,11 +1827,11 @@ int ice_cfg_vlan_pruning(struct ice_vsi *vsi, bool ena)
ctxt->info.valid_sections = cpu_to_le16(ICE_AQ_VSI_PROP_SECURITY_VALID |
ICE_AQ_VSI_PROP_SW_VALID);
- ctxt->vsi_num = vsi->vsi_num;
- status = ice_aq_update_vsi(&vsi->back->hw, ctxt, NULL);
+
+ status = ice_update_vsi(&vsi->back->hw, vsi->idx, ctxt, NULL);
if (status) {
- netdev_err(vsi->netdev, "%sabling VLAN pruning on VSI %d failed, err = %d, aq_err = %d\n",
- ena ? "Ena" : "Dis", vsi->vsi_num, status,
+ netdev_err(vsi->netdev, "%sabling VLAN pruning on VSI handle: %d, VSI HW ID: %d failed, err = %d, aq_err = %d\n",
+ ena ? "Ena" : "Dis", vsi->idx, vsi->vsi_num, status,
vsi->back->hw.adminq.sq_last_status);
goto err_out;
}
@@ -2267,7 +2265,7 @@ int ice_vsi_release(struct ice_vsi *vsi)
ice_free_res(vsi->back->irq_tracker, vsi->base_vector, vsi->idx);
pf->num_avail_msix += vsi->num_q_vectors;
- ice_remove_vsi_fltr(&pf->hw, vsi->vsi_num);
+ ice_remove_vsi_fltr(&pf->hw, vsi->idx);
ice_vsi_delete(vsi);
ice_vsi_free_q_vectors(vsi);
ice_vsi_clear_rings(vsi);
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index a3513acd272b..5fc5455e3a4d 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -3426,9 +3426,9 @@ static int ice_vsi_update_bridge_mode(struct ice_vsi *vsi, u16 bmode)
else
/* change from VEB to VEPA mode */
ctxt.info.sw_flags &= ~ICE_AQ_VSI_SW_FLAG_ALLOW_LB;
- ctxt.vsi_num = vsi->vsi_num;
ctxt.info.valid_sections = cpu_to_le16(ICE_AQ_VSI_PROP_SW_VALID);
- status = ice_aq_update_vsi(hw, &ctxt, NULL);
+
+ status = ice_update_vsi(hw, vsi->idx, &ctxt, NULL);
if (status) {
dev_err(dev, "update VSI for bridge mode failed, bmode = %d err %d aq_err %d\n",
bmode, status, hw->adminq.sq_last_status);
diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c
index 65b4e1cca6be..4e3ed541db3d 100644
--- a/drivers/net/ethernet/intel/ice/ice_switch.c
+++ b/drivers/net/ethernet/intel/ice/ice_switch.c
@@ -247,7 +247,7 @@ ice_aq_free_vsi(struct ice_hw *hw, struct ice_vsi_ctx *vsi_ctx,
*
* Update VSI context in the hardware (0x0211)
*/
-enum ice_status
+static enum ice_status
ice_aq_update_vsi(struct ice_hw *hw, struct ice_vsi_ctx *vsi_ctx,
struct ice_sq_cd *cd)
{
@@ -276,65 +276,6 @@ ice_aq_update_vsi(struct ice_hw *hw, struct ice_vsi_ctx *vsi_ctx,
return status;
}
-/**
- * ice_update_fltr_vsi_map - update given filter VSI map
- * @list_head: list for which filters needs to be updated
- * @list_lock: filter lock which needs to be updated
- * @old_vsi_num: old VSI HW id
- * @new_vsi_num: new VSI HW id
- *
- * update the VSI map for a given filter list
- */
-static void
-ice_update_fltr_vsi_map(struct list_head *list_head,
- struct mutex *list_lock, u16 old_vsi_num,
- u16 new_vsi_num)
-{
- struct ice_fltr_mgmt_list_entry *itr;
-
- mutex_lock(list_lock);
- if (list_empty(list_head))
- goto exit_update_map;
-
- list_for_each_entry(itr, list_head, list_entry) {
- if (itr->vsi_list_info &&
- test_bit(old_vsi_num, itr->vsi_list_info->vsi_map)) {
- clear_bit(old_vsi_num, itr->vsi_list_info->vsi_map);
- set_bit(new_vsi_num, itr->vsi_list_info->vsi_map);
- } else if (itr->fltr_info.fltr_act == ICE_FWD_TO_VSI &&
- itr->fltr_info.fwd_id.vsi_id == old_vsi_num) {
- itr->fltr_info.fwd_id.vsi_id = new_vsi_num;
- itr->fltr_info.src = new_vsi_num;
- }
- }
-exit_update_map:
- mutex_unlock(list_lock);
-}
-
-/**
- * ice_update_all_fltr_vsi_map - update all filters VSI map
- * @hw: pointer to the hardware structure
- * @old_vsi_num: old VSI HW id
- * @new_vsi_num: new VSI HW id
- *
- * update all filters VSI map
- */
-static void
-ice_update_all_fltr_vsi_map(struct ice_hw *hw, u16 old_vsi_num, u16 new_vsi_num)
-{
- struct ice_switch_info *sw = hw->switch_info;
- u8 i;
-
- for (i = 0; i < ICE_SW_LKUP_LAST; i++) {
- struct list_head *head = &sw->recp_list[i].filt_rules;
- struct mutex *lock; /* Lock to protect filter rule list */
-
- lock = &sw->recp_list[i].filt_rule_lock;
- ice_update_fltr_vsi_map(head, lock, old_vsi_num,
- new_vsi_num);
- }
-}
-
/**
* ice_is_vsi_valid - check whether the VSI is valid or not
* @hw: pointer to the hw struct
@@ -440,12 +381,8 @@ ice_add_vsi(struct ice_hw *hw, u16 vsi_handle, struct ice_vsi_ctx *vsi_ctx,
ice_save_vsi_ctx(hw, vsi_handle, tmp_vsi_ctx);
} else {
/* update with new HW VSI num */
- if (tmp_vsi_ctx->vsi_num != vsi_ctx->vsi_num) {
- /* update all filter lists with new HW VSI num */
- ice_update_all_fltr_vsi_map(hw, tmp_vsi_ctx->vsi_num,
- vsi_ctx->vsi_num);
+ if (tmp_vsi_ctx->vsi_num != vsi_ctx->vsi_num)
tmp_vsi_ctx->vsi_num = vsi_ctx->vsi_num;
- }
}
return status;
@@ -476,6 +413,25 @@ ice_free_vsi(struct ice_hw *hw, u16 vsi_handle, struct ice_vsi_ctx *vsi_ctx,
return status;
}
+/**
+ * ice_update_vsi
+ * @hw: pointer to the hw struct
+ * @vsi_handle: unique VSI handle
+ * @vsi_ctx: pointer to a VSI context struct
+ * @cd: pointer to command details structure or NULL
+ *
+ * Update VSI context in the hardware
+ */
+enum ice_status
+ice_update_vsi(struct ice_hw *hw, u16 vsi_handle, struct ice_vsi_ctx *vsi_ctx,
+ struct ice_sq_cd *cd)
+{
+ if (!ice_is_vsi_valid(hw, vsi_handle))
+ return ICE_ERR_PARAM;
+ vsi_ctx->vsi_num = ice_get_hw_vsi_num(hw, vsi_handle);
+ return ice_aq_update_vsi(hw, vsi_ctx, cd);
+}
+
/**
* ice_aq_alloc_free_vsi_list
* @hw: pointer to the hw struct
@@ -716,7 +672,7 @@ ice_fill_sw_rule(struct ice_hw *hw, struct ice_fltr_info *f_info,
switch (f_info->fltr_act) {
case ICE_FWD_TO_VSI:
- act |= (f_info->fwd_id.vsi_id << ICE_SINGLE_ACT_VSI_ID_S) &
+ act |= (f_info->fwd_id.hw_vsi_id << ICE_SINGLE_ACT_VSI_ID_S) &
ICE_SINGLE_ACT_VSI_ID_M;
if (f_info->lkup_type != ICE_SW_LKUP_VLAN)
act |= ICE_SINGLE_ACT_VSI_FORWARDING |
@@ -832,8 +788,8 @@ ice_add_marker_act(struct ice_hw *hw, struct ice_fltr_mgmt_list_entry *m_ent,
enum ice_status status;
u16 lg_act_size;
u16 rules_size;
- u16 vsi_info;
u32 act;
+ u16 id;
if (m_ent->fltr_info.lkup_type != ICE_SW_LKUP_MAC)
return ICE_ERR_PARAM;
@@ -859,12 +815,11 @@ ice_add_marker_act(struct ice_hw *hw, struct ice_fltr_mgmt_list_entry *m_ent,
/* First action VSI forwarding or VSI list forwarding depending on how
* many VSIs
*/
- vsi_info = (m_ent->vsi_count > 1) ?
- m_ent->fltr_info.fwd_id.vsi_list_id :
- m_ent->fltr_info.fwd_id.vsi_id;
+ id = (m_ent->vsi_count > 1) ? m_ent->fltr_info.fwd_id.vsi_list_id :
+ m_ent->fltr_info.fwd_id.hw_vsi_id;
act = ICE_LG_ACT_VSI_FORWARDING | ICE_LG_ACT_VALID_BIT;
- act |= (vsi_info << ICE_LG_ACT_VSI_LIST_ID_S) &
+ act |= (id << ICE_LG_ACT_VSI_LIST_ID_S) &
ICE_LG_ACT_VSI_LIST_ID_M;
if (m_ent->vsi_count > 1)
act |= ICE_LG_ACT_VSI_LIST;
@@ -917,15 +872,15 @@ ice_add_marker_act(struct ice_hw *hw, struct ice_fltr_mgmt_list_entry *m_ent,
/**
* ice_create_vsi_list_map
* @hw: pointer to the hardware structure
- * @vsi_array: array of VSIs to form a VSI list
- * @num_vsi: num VSI in the array
+ * @vsi_handle_arr: array of VSI handles to set in the VSI mapping
+ * @num_vsi: number of VSI handles in the array
* @vsi_list_id: VSI list id generated as part of allocate resource
*
* Helper function to create a new entry of VSI list id to VSI mapping
* using the given VSI list id
*/
static struct ice_vsi_list_map_info *
-ice_create_vsi_list_map(struct ice_hw *hw, u16 *vsi_array, u16 num_vsi,
+ice_create_vsi_list_map(struct ice_hw *hw, u16 *vsi_handle_arr, u16 num_vsi,
u16 vsi_list_id)
{
struct ice_switch_info *sw = hw->switch_info;
@@ -937,9 +892,9 @@ ice_create_vsi_list_map(struct ice_hw *hw, u16 *vsi_array, u16 num_vsi,
return NULL;
v_map->vsi_list_id = vsi_list_id;
-
+ v_map->ref_cnt = 1;
for (i = 0; i < num_vsi; i++)
- set_bit(vsi_array[i], v_map->vsi_map);
+ set_bit(vsi_handle_arr[i], v_map->vsi_map);
list_add(&v_map->list_entry, &sw->vsi_list_map_head);
return v_map;
@@ -948,8 +903,8 @@ ice_create_vsi_list_map(struct ice_hw *hw, u16 *vsi_array, u16 num_vsi,
/**
* ice_update_vsi_list_rule
* @hw: pointer to the hardware structure
- * @vsi_array: array of VSIs to form a VSI list
- * @num_vsi: num VSI in the array
+ * @vsi_handle_arr: array of VSI handles to form a VSI list
+ * @num_vsi: number of VSI handles in the array
* @vsi_list_id: VSI list id generated as part of allocate resource
* @remove: Boolean value to indicate if this is a remove action
* @opc: switch rules population command type - pass in the command opcode
@@ -959,7 +914,7 @@ ice_create_vsi_list_map(struct ice_hw *hw, u16 *vsi_array, u16 num_vsi,
* using the given VSI list id
*/
static enum ice_status
-ice_update_vsi_list_rule(struct ice_hw *hw, u16 *vsi_array, u16 num_vsi,
+ice_update_vsi_list_rule(struct ice_hw *hw, u16 *vsi_handle_arr, u16 num_vsi,
u16 vsi_list_id, bool remove, enum ice_adminq_opc opc,
enum ice_sw_lkup_type lkup_type)
{
@@ -990,9 +945,15 @@ ice_update_vsi_list_rule(struct ice_hw *hw, u16 *vsi_array, u16 num_vsi,
s_rule = devm_kzalloc(ice_hw_to_dev(hw), s_rule_size, GFP_KERNEL);
if (!s_rule)
return ICE_ERR_NO_MEMORY;
-
- for (i = 0; i < num_vsi; i++)
- s_rule->pdata.vsi_list.vsi[i] = cpu_to_le16(vsi_array[i]);
+ for (i = 0; i < num_vsi; i++) {
+ if (!ice_is_vsi_valid(hw, vsi_handle_arr[i])) {
+ status = ICE_ERR_PARAM;
+ goto exit;
+ }
+ /* AQ call requires hw_vsi_id(s) */
+ s_rule->pdata.vsi_list.vsi[i] =
+ cpu_to_le16(ice_get_hw_vsi_num(hw, vsi_handle_arr[i]));
+ }
s_rule->type = cpu_to_le16(type);
s_rule->pdata.vsi_list.number_vsi = cpu_to_le16(num_vsi);
@@ -1000,6 +961,7 @@ ice_update_vsi_list_rule(struct ice_hw *hw, u16 *vsi_array, u16 num_vsi,
status = ice_aq_sw_rules(hw, s_rule, s_rule_size, 1, opc, NULL);
+exit:
devm_kfree(ice_hw_to_dev(hw), s_rule);
return status;
}
@@ -1007,21 +969,16 @@ ice_update_vsi_list_rule(struct ice_hw *hw, u16 *vsi_array, u16 num_vsi,
/**
* ice_create_vsi_list_rule - Creates and populates a VSI list rule
* @hw: pointer to the hw struct
- * @vsi_array: array of VSIs to form a VSI list
- * @num_vsi: number of VSIs in the array
+ * @vsi_handle_arr: array of VSI handles to form a VSI list
+ * @num_vsi: number of VSI handles in the array
* @vsi_list_id: stores the ID of the VSI list to be created
* @lkup_type: switch rule filter's lookup type
*/
static enum ice_status
-ice_create_vsi_list_rule(struct ice_hw *hw, u16 *vsi_array, u16 num_vsi,
+ice_create_vsi_list_rule(struct ice_hw *hw, u16 *vsi_handle_arr, u16 num_vsi,
u16 *vsi_list_id, enum ice_sw_lkup_type lkup_type)
{
enum ice_status status;
- int i;
-
- for (i = 0; i < num_vsi; i++)
- if (vsi_array[i] >= ICE_MAX_VSI)
- return ICE_ERR_OUT_OF_RANGE;
status = ice_aq_alloc_free_vsi_list(hw, vsi_list_id, lkup_type,
ice_aqc_opc_alloc_res);
@@ -1029,9 +986,9 @@ ice_create_vsi_list_rule(struct ice_hw *hw, u16 *vsi_array, u16 num_vsi,
return status;
/* Update the newly created VSI list to include the specified VSIs */
- return ice_update_vsi_list_rule(hw, vsi_array, num_vsi, *vsi_list_id,
- false, ice_aqc_opc_add_sw_rules,
- lkup_type);
+ return ice_update_vsi_list_rule(hw, vsi_handle_arr, num_vsi,
+ *vsi_list_id, false,
+ ice_aqc_opc_add_sw_rules, lkup_type);
}
/**
@@ -1217,15 +1174,15 @@ ice_add_update_vsi_list(struct ice_hw *hw,
* new VSIs.
*/
struct ice_fltr_info tmp_fltr;
- u16 vsi_id_arr[2];
+ u16 vsi_handle_arr[2];
/* A rule already exists with the new VSI being added */
- if (cur_fltr->fwd_id.vsi_id == new_fltr->fwd_id.vsi_id)
+ if (cur_fltr->fwd_id.hw_vsi_id == new_fltr->fwd_id.hw_vsi_id)
return ICE_ERR_ALREADY_EXISTS;
- vsi_id_arr[0] = cur_fltr->fwd_id.vsi_id;
- vsi_id_arr[1] = new_fltr->fwd_id.vsi_id;
- status = ice_create_vsi_list_rule(hw, &vsi_id_arr[0], 2,
+ vsi_handle_arr[0] = cur_fltr->vsi_handle;
+ vsi_handle_arr[1] = new_fltr->vsi_handle;
+ status = ice_create_vsi_list_rule(hw, &vsi_handle_arr[0], 2,
&vsi_list_id,
new_fltr->lkup_type);
if (status)
@@ -1245,7 +1202,7 @@ ice_add_update_vsi_list(struct ice_hw *hw,
cur_fltr->fwd_id.vsi_list_id = vsi_list_id;
cur_fltr->fltr_act = ICE_FWD_TO_VSI_LIST;
m_entry->vsi_list_info =
- ice_create_vsi_list_map(hw, &vsi_id_arr[0], 2,
+ ice_create_vsi_list_map(hw, &vsi_handle_arr[0], 2,
vsi_list_id);
/* If this entry was large action then the large action needs
@@ -1257,11 +1214,11 @@ ice_add_update_vsi_list(struct ice_hw *hw,
m_entry->sw_marker_id,
m_entry->lg_act_idx);
} else {
- u16 vsi_id = new_fltr->fwd_id.vsi_id;
+ u16 vsi_handle = new_fltr->vsi_handle;
enum ice_adminq_opc opcode;
/* A rule already exists with the new VSI being added */
- if (test_bit(vsi_id, m_entry->vsi_list_info->vsi_map))
+ if (test_bit(vsi_handle, m_entry->vsi_list_info->vsi_map))
return 0;
/* Update the previously created VSI list set with
@@ -1270,12 +1227,12 @@ ice_add_update_vsi_list(struct ice_hw *hw,
vsi_list_id = cur_fltr->fwd_id.vsi_list_id;
opcode = ice_aqc_opc_update_sw_rules;
- status = ice_update_vsi_list_rule(hw, &vsi_id, 1, vsi_list_id,
- false, opcode,
+ status = ice_update_vsi_list_rule(hw, &vsi_handle, 1,
+ vsi_list_id, false, opcode,
new_fltr->lkup_type);
/* update VSI list mapping info with new VSI id */
if (!status)
- set_bit(vsi_id, m_entry->vsi_list_info->vsi_map);
+ set_bit(vsi_handle, m_entry->vsi_list_info->vsi_map);
}
if (!status)
m_entry->vsi_count++;
@@ -1310,6 +1267,39 @@ ice_find_rule_entry(struct ice_hw *hw, u8 recp_id, struct ice_fltr_info *f_info)
return ret;
}
+/**
+ * ice_find_vsi_list_entry - Search VSI list map with VSI count 1
+ * @hw: pointer to the hardware structure
+ * @recp_id: lookup type for which VSI lists needs to be searched
+ * @vsi_handle: VSI handle to be found in VSI list
+ * @vsi_list_id: VSI list id found containing vsi_handle
+ *
+ * Helper function to search a VSI list with single entry containing given VSI
+ * handle element. This can be extended further to search VSI list with more
+ * than 1 vsi_count. Returns pointer to VSI list entry if found.
+ */
+static struct ice_vsi_list_map_info *
+ice_find_vsi_list_entry(struct ice_hw *hw, u8 recp_id, u16 vsi_handle,
+ u16 *vsi_list_id)
+{
+ struct ice_vsi_list_map_info *map_info = NULL;
+ struct ice_switch_info *sw = hw->switch_info;
+ struct ice_fltr_mgmt_list_entry *list_itr;
+ struct list_head *list_head;
+
+ list_head = &sw->recp_list[recp_id].filt_rules;
+ list_for_each_entry(list_itr, list_head, list_entry) {
+ if (list_itr->vsi_count == 1 && list_itr->vsi_list_info) {
+ map_info = list_itr->vsi_list_info;
+ if (test_bit(vsi_handle, map_info->vsi_map)) {
+ *vsi_list_id = map_info->vsi_list_id;
+ return map_info;
+ }
+ }
+ }
+ return NULL;
+}
+
/**
* ice_add_rule_internal - add rule for a given lookup type
* @hw: pointer to the hardware structure
@@ -1328,6 +1318,11 @@ ice_add_rule_internal(struct ice_hw *hw, u8 recp_id,
struct mutex *rule_lock; /* Lock to protect filter rule list */
enum ice_status status = 0;
+ if (!ice_is_vsi_valid(hw, f_entry->fltr_info.vsi_handle))
+ return ICE_ERR_PARAM;
+ f_entry->fltr_info.fwd_id.hw_vsi_id =
+ ice_get_hw_vsi_num(hw, f_entry->fltr_info.vsi_handle);
+
rule_lock = &sw->recp_list[recp_id].filt_rule_lock;
mutex_lock(rule_lock);
@@ -1335,7 +1330,7 @@ ice_add_rule_internal(struct ice_hw *hw, u8 recp_id,
if (new_fltr->flag & ICE_FLTR_RX)
new_fltr->src = hw->port_info->lport;
else if (new_fltr->flag & ICE_FLTR_TX)
- new_fltr->src = f_entry->fltr_info.fwd_id.vsi_id;
+ new_fltr->src = f_entry->fltr_info.fwd_id.hw_vsi_id;
m_entry = ice_find_rule_entry(hw, recp_id, new_fltr);
if (!m_entry) {
@@ -1388,12 +1383,12 @@ ice_remove_vsi_list_rule(struct ice_hw *hw, u16 vsi_list_id,
/**
* ice_rem_update_vsi_list
* @hw: pointer to the hardware structure
- * @vsi_id: ID of the VSI to remove
+ * @vsi_handle: VSI handle of the VSI to remove
* @fm_list: filter management entry for which the VSI list management needs to
* be done
*/
static enum ice_status
-ice_rem_update_vsi_list(struct ice_hw *hw, u16 vsi_id,
+ice_rem_update_vsi_list(struct ice_hw *hw, u16 vsi_handle,
struct ice_fltr_mgmt_list_entry *fm_list)
{
enum ice_sw_lkup_type lkup_type;
@@ -1405,33 +1400,31 @@ ice_rem_update_vsi_list(struct ice_hw *hw, u16 vsi_id,
return ICE_ERR_PARAM;
/* A rule with the VSI being removed does not exist */
- if (!test_bit(vsi_id, fm_list->vsi_list_info->vsi_map))
+ if (!test_bit(vsi_handle, fm_list->vsi_list_info->vsi_map))
return ICE_ERR_DOES_NOT_EXIST;
lkup_type = fm_list->fltr_info.lkup_type;
vsi_list_id = fm_list->fltr_info.fwd_id.vsi_list_id;
-
- status = ice_update_vsi_list_rule(hw, &vsi_id, 1, vsi_list_id, true,
+ status = ice_update_vsi_list_rule(hw, &vsi_handle, 1, vsi_list_id, true,
ice_aqc_opc_update_sw_rules,
lkup_type);
if (status)
return status;
fm_list->vsi_count--;
- clear_bit(vsi_id, fm_list->vsi_list_info->vsi_map);
+ clear_bit(vsi_handle, fm_list->vsi_list_info->vsi_map);
if ((fm_list->vsi_count == 1 && lkup_type != ICE_SW_LKUP_VLAN) ||
(fm_list->vsi_count == 0 && lkup_type == ICE_SW_LKUP_VLAN)) {
struct ice_vsi_list_map_info *vsi_list_info =
fm_list->vsi_list_info;
- u16 rem_vsi_id;
+ u16 rem_vsi_handle;
- rem_vsi_id = find_first_bit(vsi_list_info->vsi_map,
- ICE_MAX_VSI);
- if (rem_vsi_id == ICE_MAX_VSI)
+ rem_vsi_handle = find_first_bit(vsi_list_info->vsi_map,
+ ICE_MAX_VSI);
+ if (!ice_is_vsi_valid(hw, rem_vsi_handle))
return ICE_ERR_OUT_OF_RANGE;
-
- status = ice_update_vsi_list_rule(hw, &rem_vsi_id, 1,
+ status = ice_update_vsi_list_rule(hw, &rem_vsi_handle, 1,
vsi_list_id, true,
ice_aqc_opc_update_sw_rules,
lkup_type);
@@ -1445,7 +1438,9 @@ ice_rem_update_vsi_list(struct ice_hw *hw, u16 vsi_id,
/* Change the list entry action from VSI_LIST to VSI */
fm_list->fltr_info.fltr_act = ICE_FWD_TO_VSI;
- fm_list->fltr_info.fwd_id.vsi_id = rem_vsi_id;
+ fm_list->fltr_info.fwd_id.hw_vsi_id =
+ ice_get_hw_vsi_num(hw, rem_vsi_handle);
+ fm_list->fltr_info.vsi_handle = rem_vsi_handle;
list_del(&vsi_list_info->list_entry);
devm_kfree(ice_hw_to_dev(hw), vsi_list_info);
@@ -1470,7 +1465,12 @@ ice_remove_rule_internal(struct ice_hw *hw, u8 recp_id,
struct mutex *rule_lock; /* Lock to protect filter rule list */
enum ice_status status = 0;
bool remove_rule = false;
- u16 vsi_id;
+ u16 vsi_handle;
+
+ if (!ice_is_vsi_valid(hw, f_entry->fltr_info.vsi_handle))
+ return ICE_ERR_PARAM;
+ f_entry->fltr_info.fwd_id.hw_vsi_id =
+ ice_get_hw_vsi_num(hw, f_entry->fltr_info.vsi_handle);
rule_lock = &sw->recp_list[recp_id].filt_rule_lock;
mutex_lock(rule_lock);
@@ -1482,9 +1482,14 @@ ice_remove_rule_internal(struct ice_hw *hw, u8 recp_id,
if (list_elem->fltr_info.fltr_act != ICE_FWD_TO_VSI_LIST) {
remove_rule = true;
+ } else if (!list_elem->vsi_list_info) {
+ status = ICE_ERR_DOES_NOT_EXIST;
+ goto exit;
} else {
- vsi_id = f_entry->fltr_info.fwd_id.vsi_id;
- status = ice_rem_update_vsi_list(hw, vsi_id, list_elem);
+ if (list_elem->vsi_list_info->ref_cnt > 1)
+ list_elem->vsi_list_info->ref_cnt--;
+ vsi_handle = f_entry->fltr_info.vsi_handle;
+ status = ice_rem_update_vsi_list(hw, vsi_handle, list_elem);
if (status)
goto exit;
/* if vsi count goes to zero after updating the vsi list */
@@ -1556,8 +1561,19 @@ ice_add_mac(struct ice_hw *hw, struct list_head *m_list)
rule_lock = &sw->recp_list[ICE_SW_LKUP_MAC].filt_rule_lock;
list_for_each_entry(m_list_itr, m_list, list_entry) {
u8 *add = &m_list_itr->fltr_info.l_data.mac.mac_addr[0];
+ u16 vsi_handle;
+ u16 hw_vsi_id;
m_list_itr->fltr_info.flag = ICE_FLTR_TX;
+ vsi_handle = m_list_itr->fltr_info.vsi_handle;
+ if (!ice_is_vsi_valid(hw, vsi_handle))
+ return ICE_ERR_PARAM;
+ hw_vsi_id = ice_get_hw_vsi_num(hw, vsi_handle);
+ m_list_itr->fltr_info.fwd_id.hw_vsi_id = hw_vsi_id;
+ /* update the src in case it is vsi num */
+ if (m_list_itr->fltr_info.src_id != ICE_SRC_ID_VSI)
+ return ICE_ERR_PARAM;
+ m_list_itr->fltr_info.src = hw_vsi_id;
if (m_list_itr->fltr_info.lkup_type != ICE_SW_LKUP_MAC ||
is_zero_ether_addr(add))
return ICE_ERR_PARAM;
@@ -1676,57 +1692,145 @@ static enum ice_status
ice_add_vlan_internal(struct ice_hw *hw, struct ice_fltr_list_entry *f_entry)
{
struct ice_switch_info *sw = hw->switch_info;
- struct ice_fltr_info *new_fltr, *cur_fltr;
struct ice_fltr_mgmt_list_entry *v_list_itr;
+ struct ice_fltr_info *new_fltr, *cur_fltr;
+ enum ice_sw_lkup_type lkup_type;
+ u16 vsi_list_id = 0, vsi_handle;
struct mutex *rule_lock; /* Lock to protect filter rule list */
enum ice_status status = 0;
+ if (!ice_is_vsi_valid(hw, f_entry->fltr_info.vsi_handle))
+ return ICE_ERR_PARAM;
+
+ f_entry->fltr_info.fwd_id.hw_vsi_id =
+ ice_get_hw_vsi_num(hw, f_entry->fltr_info.vsi_handle);
new_fltr = &f_entry->fltr_info;
+
/* VLAN id should only be 12 bits */
if (new_fltr->l_data.vlan.vlan_id > ICE_MAX_VLAN_ID)
return ICE_ERR_PARAM;
+ if (new_fltr->src_id != ICE_SRC_ID_VSI)
+ return ICE_ERR_PARAM;
+
+ new_fltr->src = new_fltr->fwd_id.hw_vsi_id;
+ lkup_type = new_fltr->lkup_type;
+ vsi_handle = new_fltr->vsi_handle;
rule_lock = &sw->recp_list[ICE_SW_LKUP_VLAN].filt_rule_lock;
mutex_lock(rule_lock);
v_list_itr = ice_find_rule_entry(hw, ICE_SW_LKUP_VLAN, new_fltr);
if (!v_list_itr) {
- u16 vsi_id = ICE_VSI_INVAL_ID;
- u16 vsi_list_id = 0;
+ struct ice_vsi_list_map_info *map_info = NULL;
if (new_fltr->fltr_act == ICE_FWD_TO_VSI) {
- enum ice_sw_lkup_type lkup_type = new_fltr->lkup_type;
-
- /* All VLAN pruning rules use a VSI list.
- * Convert the action to forwarding to a VSI list.
+ /* All VLAN pruning rules use a VSI list. Check if
+ * there is already a VSI list containing VSI that we
+ * want to add. If found, use the same vsi_list_id for
+ * this new VLAN rule or else create a new list.
*/
- vsi_id = new_fltr->fwd_id.vsi_id;
- status = ice_create_vsi_list_rule(hw, &vsi_id, 1,
- &vsi_list_id,
- lkup_type);
- if (status)
- goto exit;
+ map_info = ice_find_vsi_list_entry(hw, ICE_SW_LKUP_VLAN,
+ vsi_handle,
+ &vsi_list_id);
+ if (!map_info) {
+ status = ice_create_vsi_list_rule(hw,
+ &vsi_handle,
+ 1,
+ &vsi_list_id,
+ lkup_type);
+ if (status)
+ goto exit;
+ }
+ /* Convert the action to forwarding to a VSI list. */
new_fltr->fltr_act = ICE_FWD_TO_VSI_LIST;
new_fltr->fwd_id.vsi_list_id = vsi_list_id;
}
status = ice_create_pkt_fwd_rule(hw, f_entry);
- if (!status && vsi_id != ICE_VSI_INVAL_ID) {
+ if (!status) {
v_list_itr = ice_find_rule_entry(hw, ICE_SW_LKUP_VLAN,
new_fltr);
if (!v_list_itr) {
status = ICE_ERR_DOES_NOT_EXIST;
goto exit;
}
- v_list_itr->vsi_list_info =
- ice_create_vsi_list_map(hw, &vsi_id, 1,
- vsi_list_id);
+ /* reuse VSI list for new rule and increment ref_cnt */
+ if (map_info) {
+ v_list_itr->vsi_list_info = map_info;
+ map_info->ref_cnt++;
+ } else {
+ v_list_itr->vsi_list_info =
+ ice_create_vsi_list_map(hw, &vsi_handle,
+ 1, vsi_list_id);
+ }
}
+ } else if (v_list_itr->vsi_list_info->ref_cnt == 1) {
+ /* Update existing VSI list to add new VSI id only if it used
+ * by one VLAN rule.
+ */
+ cur_fltr = &v_list_itr->fltr_info;
+ status = ice_add_update_vsi_list(hw, v_list_itr, cur_fltr,
+ new_fltr);
+ } else {
+ /* If VLAN rule exists and VSI list being used by this rule is
+ * referenced by more than 1 VLAN rule. Then create a new VSI
+ * list appending previous VSI with new VSI and update existing
+ * VLAN rule to point to new VSI list id
+ */
+ struct ice_fltr_info tmp_fltr;
+ u16 vsi_handle_arr[2];
+ u16 cur_handle;
- goto exit;
- }
+ /* Current implementation only supports reusing VSI list with
+ * one VSI count. We should never hit below condition
+ */
+ if (v_list_itr->vsi_count > 1 &&
+ v_list_itr->vsi_list_info->ref_cnt > 1) {
+ ice_debug(hw, ICE_DBG_SW,
+ "Invalid configuration: Optimization to reuse VSI list with more than one VSI is not being done yet\n");
+ status = ICE_ERR_CFG;
+ goto exit;
+ }
- cur_fltr = &v_list_itr->fltr_info;
- status = ice_add_update_vsi_list(hw, v_list_itr, cur_fltr, new_fltr);
+ cur_handle =
+ find_first_bit(v_list_itr->vsi_list_info->vsi_map,
+ ICE_MAX_VSI);
+
+ /* A rule already exists with the new VSI being added */
+ if (cur_handle == vsi_handle) {
+ status = ICE_ERR_ALREADY_EXISTS;
+ goto exit;
+ }
+
+ vsi_handle_arr[0] = cur_handle;
+ vsi_handle_arr[1] = vsi_handle;
+ status = ice_create_vsi_list_rule(hw, &vsi_handle_arr[0], 2,
+ &vsi_list_id, lkup_type);
+ if (status)
+ goto exit;
+
+ tmp_fltr = v_list_itr->fltr_info;
+ tmp_fltr.fltr_rule_id = v_list_itr->fltr_info.fltr_rule_id;
+ tmp_fltr.fwd_id.vsi_list_id = vsi_list_id;
+ tmp_fltr.fltr_act = ICE_FWD_TO_VSI_LIST;
+ /* Update the previous switch rule to a new VSI list which
+ * includes current VSI thats requested
+ */
+ status = ice_update_pkt_fwd_rule(hw, &tmp_fltr);
+ if (status)
+ goto exit;
+
+ /* before overriding VSI list map info. decrement ref_cnt of
+ * previous VSI list
+ */
+ v_list_itr->vsi_list_info->ref_cnt--;
+
+ /* now update to newly created list */
+ v_list_itr->fltr_info.fwd_id.vsi_list_id = vsi_list_id;
+ v_list_itr->vsi_list_info =
+ ice_create_vsi_list_map(hw, &vsi_handle_arr[0], 2,
+ vsi_list_id);
+ v_list_itr->vsi_count++;
+ }
exit:
mutex_unlock(rule_lock);
@@ -1779,7 +1883,7 @@ ice_rem_sw_rule_info(struct ice_hw *hw, struct list_head *rule_head)
/**
* ice_cfg_dflt_vsi - change state of VSI to set/clear default
* @hw: pointer to the hardware structure
- * @vsi_id: number of VSI to set as default
+ * @vsi_handle: VSI handle to set as default
* @set: true to add the above mentioned switch rule, false to remove it
* @direction: ICE_FLTR_RX or ICE_FLTR_TX
*
@@ -1787,13 +1891,18 @@ ice_rem_sw_rule_info(struct ice_hw *hw, struct list_head *rule_head)
* (represented by swid)
*/
enum ice_status
-ice_cfg_dflt_vsi(struct ice_hw *hw, u16 vsi_id, bool set, u8 direction)
+ice_cfg_dflt_vsi(struct ice_hw *hw, u16 vsi_handle, bool set, u8 direction)
{
struct ice_aqc_sw_rules_elem *s_rule;
struct ice_fltr_info f_info;
enum ice_adminq_opc opcode;
enum ice_status status;
u16 s_rule_size;
+ u16 hw_vsi_id;
+
+ if (!ice_is_vsi_valid(hw, vsi_handle))
+ return ICE_ERR_PARAM;
+ hw_vsi_id = ice_get_hw_vsi_num(hw, vsi_handle);
s_rule_size = set ? ICE_SW_RULE_RX_TX_ETH_HDR_SIZE :
ICE_SW_RULE_RX_TX_NO_HDR_SIZE;
@@ -1806,15 +1915,17 @@ ice_cfg_dflt_vsi(struct ice_hw *hw, u16 vsi_id, bool set, u8 direction)
f_info.lkup_type = ICE_SW_LKUP_DFLT;
f_info.flag = direction;
f_info.fltr_act = ICE_FWD_TO_VSI;
- f_info.fwd_id.vsi_id = vsi_id;
+ f_info.fwd_id.hw_vsi_id = hw_vsi_id;
if (f_info.flag & ICE_FLTR_RX) {
f_info.src = hw->port_info->lport;
+ f_info.src_id = ICE_SRC_ID_LPORT;
if (!set)
f_info.fltr_rule_id =
hw->port_info->dflt_rx_vsi_rule_id;
} else if (f_info.flag & ICE_FLTR_TX) {
- f_info.src = vsi_id;
+ f_info.src_id = ICE_SRC_ID_VSI;
+ f_info.src = hw_vsi_id;
if (!set)
f_info.fltr_rule_id =
hw->port_info->dflt_tx_vsi_rule_id;
@@ -1834,10 +1945,10 @@ ice_cfg_dflt_vsi(struct ice_hw *hw, u16 vsi_id, bool set, u8 direction)
u16 index = le16_to_cpu(s_rule->pdata.lkup_tx_rx.index);
if (f_info.flag & ICE_FLTR_TX) {
- hw->port_info->dflt_tx_vsi_num = vsi_id;
+ hw->port_info->dflt_tx_vsi_num = hw_vsi_id;
hw->port_info->dflt_tx_vsi_rule_id = index;
} else if (f_info.flag & ICE_FLTR_RX) {
- hw->port_info->dflt_rx_vsi_num = vsi_id;
+ hw->port_info->dflt_rx_vsi_num = hw_vsi_id;
hw->port_info->dflt_rx_vsi_rule_id = index;
}
} else {
@@ -1920,21 +2031,21 @@ ice_remove_vlan(struct ice_hw *hw, struct list_head *v_list)
/**
* ice_vsi_uses_fltr - Determine if given VSI uses specified filter
* @fm_entry: filter entry to inspect
- * @vsi_id: ID of VSI to compare with filter info
+ * @vsi_handle: VSI handle to compare with filter info
*/
static bool
-ice_vsi_uses_fltr(struct ice_fltr_mgmt_list_entry *fm_entry, u16 vsi_id)
+ice_vsi_uses_fltr(struct ice_fltr_mgmt_list_entry *fm_entry, u16 vsi_handle)
{
return ((fm_entry->fltr_info.fltr_act == ICE_FWD_TO_VSI &&
- fm_entry->fltr_info.fwd_id.vsi_id == vsi_id) ||
+ fm_entry->fltr_info.vsi_handle == vsi_handle) ||
(fm_entry->fltr_info.fltr_act == ICE_FWD_TO_VSI_LIST &&
- (test_bit(vsi_id, fm_entry->vsi_list_info->vsi_map))));
+ (test_bit(vsi_handle, fm_entry->vsi_list_info->vsi_map))));
}
/**
* ice_add_entry_to_vsi_fltr_list - Add copy of fltr_list_entry to remove list
* @hw: pointer to the hardware structure
- * @vsi_id: ID of VSI to remove filters from
+ * @vsi_handle: VSI handle to remove filters from
* @vsi_list_head: pointer to the list to add entry to
* @fi: pointer to fltr_info of filter entry to copy & add
*
@@ -1945,7 +2056,7 @@ ice_vsi_uses_fltr(struct ice_fltr_mgmt_list_entry *fm_entry, u16 vsi_id)
* extract which VSI to remove the fltr from, and pass on that information.
*/
static enum ice_status
-ice_add_entry_to_vsi_fltr_list(struct ice_hw *hw, u16 vsi_id,
+ice_add_entry_to_vsi_fltr_list(struct ice_hw *hw, u16 vsi_handle,
struct list_head *vsi_list_head,
struct ice_fltr_info *fi)
{
@@ -1966,7 +2077,8 @@ ice_add_entry_to_vsi_fltr_list(struct ice_hw *hw, u16 vsi_id,
* values.
*/
tmp->fltr_info.fltr_act = ICE_FWD_TO_VSI;
- tmp->fltr_info.fwd_id.vsi_id = vsi_id;
+ tmp->fltr_info.vsi_handle = vsi_handle;
+ tmp->fltr_info.fwd_id.hw_vsi_id = ice_get_hw_vsi_num(hw, vsi_handle);
list_add(&tmp->list_entry, vsi_list_head);
@@ -1976,9 +2088,9 @@ ice_add_entry_to_vsi_fltr_list(struct ice_hw *hw, u16 vsi_id,
/**
* ice_add_to_vsi_fltr_list - Add VSI filters to the list
* @hw: pointer to the hardware structure
- * @vsi_id: ID of VSI to remove filters from
+ * @vsi_handle: VSI handle to remove filters from
* @lkup_list_head: pointer to the list that has certain lookup type filters
- * @vsi_list_head: pointer to the list pertaining to VSI with vsi_id
+ * @vsi_list_head: pointer to the list pertaining to VSI with vsi_handle
*
* Locates all filters in lkup_list_head that are used by the given VSI,
* and adds COPIES of those entries to vsi_list_head (intended to be used
@@ -1987,7 +2099,7 @@ ice_add_entry_to_vsi_fltr_list(struct ice_hw *hw, u16 vsi_id,
* deallocated by the caller when done with list.
*/
static enum ice_status
-ice_add_to_vsi_fltr_list(struct ice_hw *hw, u16 vsi_id,
+ice_add_to_vsi_fltr_list(struct ice_hw *hw, u16 vsi_handle,
struct list_head *lkup_list_head,
struct list_head *vsi_list_head)
{
@@ -1995,17 +2107,17 @@ ice_add_to_vsi_fltr_list(struct ice_hw *hw, u16 vsi_id,
enum ice_status status = 0;
/* check to make sure VSI id is valid and within boundary */
- if (vsi_id >= ICE_MAX_VSI)
+ if (!ice_is_vsi_valid(hw, vsi_handle))
return ICE_ERR_PARAM;
list_for_each_entry(fm_entry, lkup_list_head, list_entry) {
struct ice_fltr_info *fi;
fi = &fm_entry->fltr_info;
- if (!ice_vsi_uses_fltr(fm_entry, vsi_id))
+ if (!ice_vsi_uses_fltr(fm_entry, vsi_handle))
continue;
- status = ice_add_entry_to_vsi_fltr_list(hw, vsi_id,
+ status = ice_add_entry_to_vsi_fltr_list(hw, vsi_handle,
vsi_list_head, fi);
if (status)
return status;
@@ -2016,11 +2128,11 @@ ice_add_to_vsi_fltr_list(struct ice_hw *hw, u16 vsi_id,
/**
* ice_remove_vsi_lkup_fltr - Remove lookup type filters for a VSI
* @hw: pointer to the hardware structure
- * @vsi_id: ID of VSI to remove filters from
+ * @vsi_handle: VSI handle to remove filters from
* @lkup: switch rule filter lookup type
*/
static void
-ice_remove_vsi_lkup_fltr(struct ice_hw *hw, u16 vsi_id,
+ice_remove_vsi_lkup_fltr(struct ice_hw *hw, u16 vsi_handle,
enum ice_sw_lkup_type lkup)
{
struct ice_switch_info *sw = hw->switch_info;
@@ -2035,7 +2147,7 @@ ice_remove_vsi_lkup_fltr(struct ice_hw *hw, u16 vsi_id,
rule_lock = &sw->recp_list[lkup].filt_rule_lock;
rule_head = &sw->recp_list[lkup].filt_rules;
mutex_lock(rule_lock);
- status = ice_add_to_vsi_fltr_list(hw, vsi_id, rule_head,
+ status = ice_add_to_vsi_fltr_list(hw, vsi_handle, rule_head,
&remove_list_head);
mutex_unlock(rule_lock);
if (status)
@@ -2069,18 +2181,18 @@ ice_remove_vsi_lkup_fltr(struct ice_hw *hw, u16 vsi_id,
/**
* ice_remove_vsi_fltr - Remove all filters for a VSI
* @hw: pointer to the hardware structure
- * @vsi_id: ID of VSI to remove filters from
+ * @vsi_handle: VSI handle to remove filters from
*/
-void ice_remove_vsi_fltr(struct ice_hw *hw, u16 vsi_id)
+void ice_remove_vsi_fltr(struct ice_hw *hw, u16 vsi_handle)
{
- ice_remove_vsi_lkup_fltr(hw, vsi_id, ICE_SW_LKUP_MAC);
- ice_remove_vsi_lkup_fltr(hw, vsi_id, ICE_SW_LKUP_MAC_VLAN);
- ice_remove_vsi_lkup_fltr(hw, vsi_id, ICE_SW_LKUP_PROMISC);
- ice_remove_vsi_lkup_fltr(hw, vsi_id, ICE_SW_LKUP_VLAN);
- ice_remove_vsi_lkup_fltr(hw, vsi_id, ICE_SW_LKUP_DFLT);
- ice_remove_vsi_lkup_fltr(hw, vsi_id, ICE_SW_LKUP_ETHERTYPE);
- ice_remove_vsi_lkup_fltr(hw, vsi_id, ICE_SW_LKUP_ETHERTYPE_MAC);
- ice_remove_vsi_lkup_fltr(hw, vsi_id, ICE_SW_LKUP_PROMISC_VLAN);
+ ice_remove_vsi_lkup_fltr(hw, vsi_handle, ICE_SW_LKUP_MAC);
+ ice_remove_vsi_lkup_fltr(hw, vsi_handle, ICE_SW_LKUP_MAC_VLAN);
+ ice_remove_vsi_lkup_fltr(hw, vsi_handle, ICE_SW_LKUP_PROMISC);
+ ice_remove_vsi_lkup_fltr(hw, vsi_handle, ICE_SW_LKUP_VLAN);
+ ice_remove_vsi_lkup_fltr(hw, vsi_handle, ICE_SW_LKUP_DFLT);
+ ice_remove_vsi_lkup_fltr(hw, vsi_handle, ICE_SW_LKUP_ETHERTYPE);
+ ice_remove_vsi_lkup_fltr(hw, vsi_handle, ICE_SW_LKUP_ETHERTYPE_MAC);
+ ice_remove_vsi_lkup_fltr(hw, vsi_handle, ICE_SW_LKUP_PROMISC_VLAN);
}
/**
@@ -2129,7 +2241,7 @@ ice_replay_fltr(struct ice_hw *hw, u8 recp_id, struct list_head *list_head)
break;
clear_bit(vsi, itr->vsi_list_info->vsi_map);
- f_entry.fltr_info.fwd_id.vsi_id = vsi;
+ f_entry.fltr_info.fwd_id.hw_vsi_id = vsi;
f_entry.fltr_info.fltr_act = ICE_FWD_TO_VSI;
if (recp_id == ICE_SW_LKUP_VLAN)
status = ice_add_vlan_internal(hw, &f_entry);
diff --git a/drivers/net/ethernet/intel/ice/ice_switch.h b/drivers/net/ethernet/intel/ice/ice_switch.h
index e12940e70000..c188bbc3de2a 100644
--- a/drivers/net/ethernet/intel/ice/ice_switch.h
+++ b/drivers/net/ethernet/intel/ice/ice_switch.h
@@ -42,6 +42,14 @@ enum ice_sw_lkup_type {
ICE_SW_LKUP_LAST
};
+/* type of filter src id */
+enum ice_src_id {
+ ICE_SRC_ID_UNKNOWN = 0,
+ ICE_SRC_ID_VSI,
+ ICE_SRC_ID_QUEUE,
+ ICE_SRC_ID_LPORT,
+};
+
struct ice_fltr_info {
/* Look up information: how to look up packet */
enum ice_sw_lkup_type lkup_type;
@@ -56,6 +64,7 @@ struct ice_fltr_info {
/* Source VSI for LOOKUP_TX or source port for LOOKUP_RX */
u16 src;
+ enum ice_src_id src_id;
union {
struct {
@@ -77,7 +86,10 @@ struct ice_fltr_info {
u16 ethertype;
u8 mac_addr[ETH_ALEN]; /* optional */
} ethertype_mac;
- } l_data;
+ } l_data; /* Make sure to zero out the memory of l_data before using
+ * it or only set the data associated with lookup match
+ * rest everything should be zero
+ */
/* Depending on filter action */
union {
@@ -85,12 +97,16 @@ struct ice_fltr_info {
* queue id in case of ICE_FWD_TO_QGRP.
*/
u16 q_id:11;
- u16 vsi_id:10;
+ u16 hw_vsi_id:10;
u16 vsi_list_id:10;
} fwd_id;
+ /* Sw VSI handle */
+ u16 vsi_handle;
+
/* Set to num_queues if action is ICE_FWD_TO_QGRP. This field
- * determines the range of queues the packet needs to be forwarded to
+ * determines the range of queues the packet needs to be forwarded to.
+ * Note that qgrp_size must be set to a power of 2.
*/
u8 qgrp_size;
@@ -129,6 +145,8 @@ struct ice_vsi_list_map_info {
struct list_head list_entry;
DECLARE_BITMAP(vsi_map, ICE_MAX_VSI);
u16 vsi_list_id;
+ /* counter to track how many rules are reusing this VSI list */
+ u16 ref_cnt;
};
struct ice_fltr_list_entry {
@@ -159,25 +177,25 @@ struct ice_fltr_mgmt_list_entry {
/* VSI related commands */
enum ice_status
-ice_aq_update_vsi(struct ice_hw *hw, struct ice_vsi_ctx *vsi_ctx,
- struct ice_sq_cd *cd);
-enum ice_status
ice_add_vsi(struct ice_hw *hw, u16 vsi_handle, struct ice_vsi_ctx *vsi_ctx,
struct ice_sq_cd *cd);
enum ice_status
ice_free_vsi(struct ice_hw *hw, u16 vsi_handle, struct ice_vsi_ctx *vsi_ctx,
bool keep_vsi_alloc, struct ice_sq_cd *cd);
+enum ice_status
+ice_update_vsi(struct ice_hw *hw, u16 vsi_handle, struct ice_vsi_ctx *vsi_ctx,
+ struct ice_sq_cd *cd);
enum ice_status ice_get_initial_sw_cfg(struct ice_hw *hw);
/* Switch/bridge related commands */
enum ice_status ice_update_sw_rule_bridge_mode(struct ice_hw *hw);
enum ice_status ice_add_mac(struct ice_hw *hw, struct list_head *m_lst);
enum ice_status ice_remove_mac(struct ice_hw *hw, struct list_head *m_lst);
-void ice_remove_vsi_fltr(struct ice_hw *hw, u16 vsi_id);
+void ice_remove_vsi_fltr(struct ice_hw *hw, u16 vsi_handle);
enum ice_status ice_add_vlan(struct ice_hw *hw, struct list_head *m_list);
enum ice_status ice_remove_vlan(struct ice_hw *hw, struct list_head *v_list);
enum ice_status
-ice_cfg_dflt_vsi(struct ice_hw *hw, u16 vsi_id, bool set, u8 direction);
+ice_cfg_dflt_vsi(struct ice_hw *hw, u16 vsi_handle, bool set, u8 direction);
enum ice_status ice_replay_all_fltr(struct ice_hw *hw);
--
2.17.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