* [PATCH net-next 09/12] nfp: don't wait for resources indefinitely
From: Jakub Kicinski @ 2017-05-28 0:34 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Jakub Kicinski
In-Reply-To: <20170528003411.17603-1-jakub.kicinski@netronome.com>
There is currently no timeout to the resource and lock acquiring
loops. We printed warnings and depended on user sending a signal
to the waiting process to stop the waiting. This doesn't work
very well when wait happens out of a work queue. The simplest
example of that is PCI probe. When user loads the module and card
is in a broken state modprobe will wait forever and signals sent
to it will not actually reach the probing thread.
Make sure all wait loops have a time out. Set the upper wait time
to 60 seconds to stay on the safe side.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cpp.h | 5 +++++
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_mutex.c | 9 +++++++--
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c | 10 ++++++++--
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cpp.h b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cpp.h
index 8d46b9acb69f..0a46c0984e68 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cpp.h
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cpp.h
@@ -63,6 +63,11 @@
/* Max size of area it should be safe to request */
#define NFP_CPP_SAFE_AREA_SIZE SZ_2M
+/* NFP_MUTEX_WAIT_* are timeouts in seconds when waiting for a mutex */
+#define NFP_MUTEX_WAIT_FIRST_WARN 15
+#define NFP_MUTEX_WAIT_NEXT_WARN 5
+#define NFP_MUTEX_WAIT_ERROR 60
+
struct device;
struct nfp_cpp_area;
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_mutex.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_mutex.c
index 8a99c189efa8..f7b958181126 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_mutex.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_mutex.c
@@ -195,7 +195,8 @@ void nfp_cpp_mutex_free(struct nfp_cpp_mutex *mutex)
*/
int nfp_cpp_mutex_lock(struct nfp_cpp_mutex *mutex)
{
- unsigned long warn_at = jiffies + 15 * HZ;
+ unsigned long warn_at = jiffies + NFP_MUTEX_WAIT_FIRST_WARN * HZ;
+ unsigned long err_at = jiffies + NFP_MUTEX_WAIT_ERROR * HZ;
unsigned int timeout_ms = 1;
int err;
@@ -214,12 +215,16 @@ int nfp_cpp_mutex_lock(struct nfp_cpp_mutex *mutex)
return -ERESTARTSYS;
if (time_is_before_eq_jiffies(warn_at)) {
- warn_at = jiffies + 60 * HZ;
+ warn_at = jiffies + NFP_MUTEX_WAIT_NEXT_WARN * HZ;
nfp_warn(mutex->cpp,
"Warning: waiting for NFP mutex [depth:%hd target:%d addr:%llx key:%08x]\n",
mutex->depth,
mutex->target, mutex->address, mutex->key);
}
+ if (time_is_before_eq_jiffies(err_at)) {
+ nfp_err(mutex->cpp, "Error: mutex wait timed out\n");
+ return -EBUSY;
+ }
}
return err;
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c
index 2d15a7c9d0de..072612263dab 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c
@@ -181,7 +181,8 @@ nfp_resource_try_acquire(struct nfp_cpp *cpp, struct nfp_resource *res,
struct nfp_resource *
nfp_resource_acquire(struct nfp_cpp *cpp, const char *name)
{
- unsigned long warn_at = jiffies + 15 * HZ;
+ unsigned long warn_at = jiffies + NFP_MUTEX_WAIT_FIRST_WARN * HZ;
+ unsigned long err_at = jiffies + NFP_MUTEX_WAIT_ERROR * HZ;
struct nfp_cpp_mutex *dev_mutex;
struct nfp_resource *res;
int err;
@@ -214,10 +215,15 @@ nfp_resource_acquire(struct nfp_cpp *cpp, const char *name)
}
if (time_is_before_eq_jiffies(warn_at)) {
- warn_at = jiffies + 60 * HZ;
+ warn_at = jiffies + NFP_MUTEX_WAIT_NEXT_WARN * HZ;
nfp_warn(cpp, "Warning: waiting for NFP resource %s\n",
name);
}
+ if (time_is_before_eq_jiffies(err_at)) {
+ nfp_err(cpp, "Error: resource %s timed out\n", name);
+ err = -EBUSY;
+ goto err_free;
+ }
}
nfp_cpp_mutex_free(dev_mutex);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 11/12] nfp: don't add ring size to index calculations
From: Jakub Kicinski @ 2017-05-28 0:34 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Jakub Kicinski
In-Reply-To: <20170528003411.17603-1-jakub.kicinski@netronome.com>
Adding ring size to index calculation is pointless, since index
will be masked with ring size - 1.
Suggested-by: David Laight <David.Laight@ACULAB.COM>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 9312a737fbc9..68013d048e9d 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -928,7 +928,7 @@ static void nfp_net_tx_complete(struct nfp_net_tx_ring *tx_ring)
if (qcp_rd_p == tx_ring->qcp_rd_p)
return;
- todo = D_IDX(tx_ring, qcp_rd_p + tx_ring->cnt - tx_ring->qcp_rd_p);
+ todo = D_IDX(tx_ring, qcp_rd_p - tx_ring->qcp_rd_p);
while (todo--) {
idx = D_IDX(tx_ring, tx_ring->rd_p++);
@@ -999,7 +999,7 @@ static bool nfp_net_xdp_complete(struct nfp_net_tx_ring *tx_ring)
if (qcp_rd_p == tx_ring->qcp_rd_p)
return true;
- todo = D_IDX(tx_ring, qcp_rd_p + tx_ring->cnt - tx_ring->qcp_rd_p);
+ todo = D_IDX(tx_ring, qcp_rd_p - tx_ring->qcp_rd_p);
done_all = todo <= NFP_NET_XDP_MAX_COMPLETE;
todo = min(todo, NFP_NET_XDP_MAX_COMPLETE);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 10/12] nfp: fix print format for ring pointers in ring dumps
From: Jakub Kicinski @ 2017-05-28 0:34 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Jakub Kicinski
In-Reply-To: <20170528003411.17603-1-jakub.kicinski@netronome.com>
Ring pointers are unsigned. Fix the print formats to avoid
showing users negative values.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c b/drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c
index 6cf1b234eecd..8c52c0e8379c 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c
@@ -62,7 +62,7 @@ static int nfp_net_debugfs_rx_q_read(struct seq_file *file, void *data)
fl_rd_p = nfp_qcp_rd_ptr_read(rx_ring->qcp_fl);
fl_wr_p = nfp_qcp_wr_ptr_read(rx_ring->qcp_fl);
- seq_printf(file, "RX[%02d,%02d]: cnt=%d dma=%pad host=%p H_RD=%d H_WR=%d FL_RD=%d FL_WR=%d\n",
+ seq_printf(file, "RX[%02d,%02d]: cnt=%u dma=%pad host=%p H_RD=%u H_WR=%u FL_RD=%u FL_WR=%u\n",
rx_ring->idx, rx_ring->fl_qcidx,
rx_ring->cnt, &rx_ring->dma, rx_ring->rxds,
rx_ring->rd_p, rx_ring->wr_p, fl_rd_p, fl_wr_p);
@@ -146,7 +146,7 @@ static int nfp_net_debugfs_tx_q_read(struct seq_file *file, void *data)
d_rd_p = nfp_qcp_rd_ptr_read(tx_ring->qcp_q);
d_wr_p = nfp_qcp_wr_ptr_read(tx_ring->qcp_q);
- seq_printf(file, "TX[%02d,%02d%s]: cnt=%d dma=%pad host=%p H_RD=%d H_WR=%d D_RD=%d D_WR=%d\n",
+ seq_printf(file, "TX[%02d,%02d%s]: cnt=%u dma=%pad host=%p H_RD=%u H_WR=%u D_RD=%u D_WR=%u\n",
tx_ring->idx, tx_ring->qcidx,
tx_ring == r_vec->tx_ring ? "" : "xdp",
tx_ring->cnt, &tx_ring->dma, tx_ring->txds,
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 12/12] nfp: don't keep count for free buffers delayed kick
From: Jakub Kicinski @ 2017-05-28 0:34 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Jakub Kicinski
In-Reply-To: <20170528003411.17603-1-jakub.kicinski@netronome.com>
We only kick RX free buffer queue controller every NFP_NET_FL_BATCH
(currently 16) entries. This means that we will always kick the QC
when write ring index is divisable by NFP_NET_FL_BATCH. There is
no need to keep counts.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net.h | 3 ---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 7 ++-----
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net.h b/drivers/net/ethernet/netronome/nfp/nfp_net.h
index 7882d2604835..cb7114309656 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net.h
@@ -328,8 +328,6 @@ struct nfp_net_rx_buf {
* @idx: Ring index from Linux's perspective
* @fl_qcidx: Queue Controller Peripheral (QCP) queue index for the freelist
* @qcp_fl: Pointer to base of the QCP freelist queue
- * @wr_ptr_add: Accumulated number of buffers to add to QCP write pointer
- * (used for free list batching)
* @rxbufs: Array of transmitted FL/RX buffers
* @rxds: Virtual address of FL/RX ring in host memory
* @dma: DMA address of the FL/RX ring
@@ -343,7 +341,6 @@ struct nfp_net_rx_ring {
u32 rd_p;
u32 idx;
- u32 wr_ptr_add;
int fl_qcidx;
u8 __iomem *qcp_fl;
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 68013d048e9d..c9a140376621 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -1212,14 +1212,12 @@ static void nfp_net_rx_give_one(const struct nfp_net_dp *dp,
dma_addr + dp->rx_dma_off);
rx_ring->wr_p++;
- rx_ring->wr_ptr_add++;
- if (rx_ring->wr_ptr_add >= NFP_NET_FL_BATCH) {
+ if (!(rx_ring->wr_p % NFP_NET_FL_BATCH)) {
/* Update write pointer of the freelist queue. Make
* sure all writes are flushed before telling the hardware.
*/
wmb();
- nfp_qcp_wr_ptr_add(rx_ring->qcp_fl, rx_ring->wr_ptr_add);
- rx_ring->wr_ptr_add = 0;
+ nfp_qcp_wr_ptr_add(rx_ring->qcp_fl, NFP_NET_FL_BATCH);
}
}
@@ -1245,7 +1243,6 @@ static void nfp_net_rx_ring_reset(struct nfp_net_rx_ring *rx_ring)
memset(rx_ring->rxds, 0, sizeof(*rx_ring->rxds) * rx_ring->cnt);
rx_ring->wr_p = 0;
rx_ring->rd_p = 0;
- rx_ring->wr_ptr_add = 0;
}
/**
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 net-next 3/9] net: lwtunnel: Add extack to encap attr validation
From: kbuild test robot @ 2017-05-28 1:02 UTC (permalink / raw)
To: David Ahern; +Cc: kbuild-all, netdev, roopa, David Ahern
In-Reply-To: <20170527221933.57644-4-dsahern@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
Hi David,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/David-Ahern/net-another-round-of-extack-handling-for-routing/20170528-062659
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
Note: the linux-review/David-Ahern/net-another-round-of-extack-handling-for-routing/20170528-062659 HEAD 44d11f94ccbe86e1a088f83a49ef3ca473118ad8 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
ERROR: "ia64_delay_loop" [drivers/spi/spi-thunderx.ko] undefined!
>> ERROR: "ia64_delay_loop" [drivers/net/phy/mdio-cavium.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 47727 bytes --]
^ permalink raw reply
* [net-next:master 329/368] serdes.c:(.text+0x12f): multiple definition of `mv88e6xxx_g2_pvt_write'
From: kbuild test robot @ 2017-05-28 1:16 UTC (permalink / raw)
To: Andrew Lunn; +Cc: kbuild-all, netdev, Vivien Didelot
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: a3995460491d4570af8e99ad34ddf6d1948254d9
commit: 6335e9f2446b44139ac0722a81759a2b2f90bb4c [329/368] net: dsa: mv88e6xxx: mv88e6390X SERDES support
config: i386-randconfig-i1-05241633 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
git checkout 6335e9f2446b44139ac0722a81759a2b2f90bb4c
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/net/dsa/mv88e6xxx/serdes.o: In function `mv88e6xxx_g2_pvt_write':
>> serdes.c:(.text+0x12f): multiple definition of `mv88e6xxx_g2_pvt_write'
drivers/net/dsa/mv88e6xxx/chip.o:chip.c:(.text+0x23f3): first defined here
drivers/net/dsa/mv88e6xxx/serdes.o: In function `mv88e6xxx_g2_misc_4_bit_port':
>> serdes.c:(.text+0x13e): multiple definition of `mv88e6xxx_g2_misc_4_bit_port'
drivers/net/dsa/mv88e6xxx/chip.o:chip.c:(.text+0x2402): first defined here
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32297 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] mlx5: Do not build eswitch_offloads if CONFIG_MLX5_EN_ESWITCH_OFFLOADS is set
From: Jes Sorensen @ 2017-05-28 2:23 UTC (permalink / raw)
To: Or Gerlitz
Cc: Linux Netdev List, Kernel Team, Saeed Mahameed, Ilan Tayari,
Jes Sorensen
In-Reply-To: <CAJ3xEMgeBaE9q6sucXtOQTBLAvZvf_d0eGvMsGbVa2vWc21R-Q@mail.gmail.com>
On 05/27/2017 05:02 PM, Or Gerlitz wrote:
> On Sat, May 27, 2017 at 12:16 AM, Jes Sorensen <jes.sorensen@gmail.com> wrote:
>> This gets rid of the temporary #ifdef spaghetti and allows the code to
>> compile without offload support enabled.
>
> Hi Jes,
>
> I am pretty sure we can do that exercise you're up to without any
> spaghetti cooking and even put more code under that CONFIG directive
> (en_rep.c), I'll take that with Saeed.
Hi Or,
I want to avoid adding #ifdef CONFIG_foo to the main code in order to
keep it readable. I did it gradually to make sure I didn't break
anything and to allow for it to be bisected in case something did break.
If we can move out more code from places like en_rep.c into
eswitch_offload.c and get it disabled that way that would be great, but
I like to limit the number of #ifdefs we add to the actual code.
> Just wondering, you are motivated by a wish to put some mlx5
> functionalities under their own CONFIG directives which could be
> useful when backporting the latest upstream driver into older kernel
> and being able not to deal with parts of it, right? in that respect,
> are you using SRIOV but not the offloads mode?
The motivation is two-fold, the primary is to be able to disable
features not being used for those who compile a custom kernel and who
wish to reduce the codebase compiled. It also makes it more flexible
when back porting the code to older kernels since it is easier to pick
out a smaller subset. I was going to look into making TC support etc.
optional next, but I wanted to have a discussion about this patchset first.
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH v2 net-next 3/9] net: lwtunnel: Add extack to encap attr validation
From: David Ahern @ 2017-05-28 2:44 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, netdev, roopa
In-Reply-To: <201705280846.ceaILiWY%fengguang.wu@intel.com>
On 5/27/17 7:02 PM, kbuild test robot wrote:
> Hi David,
>
> [auto build test ERROR on net-next/master]
>
> url: https://github.com/0day-ci/linux/commits/David-Ahern/net-another-round-of-extack-handling-for-routing/20170528-062659
> config: ia64-allmodconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 6.2.0
> reproduce:
> wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=ia64
>
> Note: the linux-review/David-Ahern/net-another-round-of-extack-handling-for-routing/20170528-062659 HEAD 44d11f94ccbe86e1a088f83a49ef3ca473118ad8 builds fine.
> It only hurts bisectibility.
>
> All errors (new ones prefixed by >>):
>
> ERROR: "ia64_delay_loop" [drivers/spi/spi-thunderx.ko] undefined!
>>> ERROR: "ia64_delay_loop" [drivers/net/phy/mdio-cavium.ko] undefined!
Appears to be a false positive. I do not modify anything related to
delay loops and none of this code is arch specific.
kbuild guys: can you clarify?
^ permalink raw reply
* Re: running an eBPF program
From: Y Song @ 2017-05-28 5:08 UTC (permalink / raw)
To: David Miller; +Cc: Adel Fuchs, netdev
In-Reply-To: <20170527.201107.1558140531080967167.davem@davemloft.net>
On Sat, May 27, 2017 at 5:11 PM, David Miller <davem@davemloft.net> wrote:
> From: Y Song <ys114321@gmail.com>
> Date: Sat, 27 May 2017 13:52:27 -0700
>
>> On Sat, May 27, 2017 at 1:23 PM, Y Song <ys114321@gmail.com> wrote:
>>>
>>> From verifier error message:
>>> ======
>>> 0: (bf) r6 = r1
>>>
>>> 1: (18) r9 = 0xffe0000e
>>>
>>> 3: (69) r0 = *(u16 *)(r6 +16)
>>>
>>> invalid bpf_context access off=16 size=2
>>> ======
>>>
>>> The offset 16 of struct __sk_buff is hash.
>>> What instruction #3 tries to do is to access 2 bytes of the hash value
>>> instead of full 4 bytes.
>>> This is explicitly not allowed in verifier due to endianness issue.
>>
>>
>> I can reproduce the issue now. My previous statement saying to access
>> "hash" field is not correct. It is accessing the protocol field.
>>
>> static __inline__ bool flow_dissector(struct __sk_buff *skb,
>> struct flow_keys *flow)
>> {
>> int poff, nh_off = BPF_LL_OFF + ETH_HLEN;
>> __be16 proto = skb->protocol;
>> __u8 ip_proto;
>>
>> The plan so far is to see whether we can fix the issue in LLVM side.
>
> If the compiler properly asks for "__sk_buff + 16" on little-endian
> and "__sk_buff + 20" on big-endian, the verifier should instead be
> fixed to allow the access to pass.
>
> I can't see any reason why LLVM won't set the offset properly like
> that, and it's a completely legitimate optimization that we shouldn't
> try to stop LLVM from performing.
I do agree that such optimization in LLVM is perfect fine and actually
beneficial.
The only reason I was thinking was to avoid introduce endianness into verifier.
Maybe not too much work there. Let me do some experiments and come with
a patch for that.
Thanks!
Yonghong
>
> It also makes it so that we don't have to fix having absurdly defined
> __sk_buff's protocol field as a u32.
>
> Thanks.
^ permalink raw reply
* Re: [PATCH 7/7] mlx5: Do not build eswitch_offloads if CONFIG_MLX5_EN_ESWITCH_OFFLOADS is set
From: Or Gerlitz @ 2017-05-28 6:03 UTC (permalink / raw)
To: Jes Sorensen
Cc: Linux Netdev List, Kernel Team, Saeed Mahameed, Ilan Tayari,
Jes Sorensen
In-Reply-To: <e7c36f4e-788a-89dd-e92e-e6a31004758a@gmail.com>
On Sun, May 28, 2017 at 5:23 AM, Jes Sorensen <jes.sorensen@gmail.com> wrote:
> On 05/27/2017 05:02 PM, Or Gerlitz wrote:
>>
>> On Sat, May 27, 2017 at 12:16 AM, Jes Sorensen <jes.sorensen@gmail.com>
>> wrote:
>>>
>>> This gets rid of the temporary #ifdef spaghetti and allows the code to
>>> compile without offload support enabled.
>> I am pretty sure we can do that exercise you're up to without any
>> spaghetti cooking and even put more code under that CONFIG directive
>> (en_rep.c), I'll take that with Saeed.
> I want to avoid adding #ifdef CONFIG_foo to the main code in order to keep
> it readable. I did it gradually to make sure I didn't break anything and to
> allow for it to be bisected in case something did break. If we can move out
> more code from places like en_rep.c into eswitch_offload.c and get it
> disabled that way that would be great, but I like to limit the number of
> #ifdefs we add to the actual code.
FWIW (see below), squashing your seven patches to one resulted in a
fairly simple/clear
patch, so if we go that way, no need to have seven commits just for this piece.
>> Just wondering, you are motivated by a wish to put some mlx5
>> functionalities under their own CONFIG directives which could be
>> useful when backporting the latest upstream driver into older kernel
>> and being able not to deal with parts of it, right? in that respect,
>> are you using SRIOV but not the offloads mode?
> The motivation is two-fold, the primary is to be able to disable features
> not being used for those who compile a custom kernel and who wish to reduce
> the codebase compiled. It also makes it more flexible when back porting the
> code to older kernels since it is easier to pick out a smaller subset. I was
> going to look into making TC support etc. optional next, but I wanted to
> have a discussion about this patchset first.
OKay, I got you.
Re SRIOV, I don't think it would be correct to break the support info few
CONFIG directives. If we want to allow someone to build the driver w.o
SRIOV that's fine, but I don't think we should further go down and disable
some of the SRIOV sub-modes.
Re TC offload support, that's make sense.
Or.
^ permalink raw reply
* RE: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
From: Ilan Tayari @ 2017-05-28 7:22 UTC (permalink / raw)
To: Jason Gunthorpe, Alexei Starovoitov
Cc: Saeed Mahameed, David S. Miller, Doug Ledford,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jsorensen-b10kYP2dOMg@public.gmane.org, Andy Shevchenko,
linux-fpga-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Alan Tull,
yi1.li-VuQAYsv1563Yd54FQh9/CA@public.gmane.org, Boris Pismenny
In-Reply-To: <20170526181517.GA3860-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgunthorpe@obsidianresearch.com]
>
> On Fri, May 26, 2017 at 10:56:25AM -0700, Alexei Starovoitov wrote:
>
> > > for that feature which is the originating place, before defining
> > > APIs/infrastructures,
> > > until the feature is complete and every body is happy about it.
> >
> > There is driver/fpga to manage fpga, but mlx fpga+nic combo
> > will be managed via mlx5/core/fpga/
> >
> > Adding fpga folks for visibility.
>
> It would be good to use the existing fpga loading infrastructure to
> get the bitstream into the NIC, and to use the same Xilinx bitstream
> format as eg Zynq does for consistency.
>
> I'm unclear how this works - there must be more to it than just a
> 'bump on the wire', there must be some communication channel between
> the FPGA and Linux to set operational data (eg load keys) etc.
>
> If that is register mapped into a PCI-BAR someplace then it really
> should use the FPGA layer functions to manage binding drivers to that
> register window.
>
> If it is mailbox command based then it is not as good of a fit.
>
Hi Jason,
Thanks for taking the time to consider this!
This is neither PCI-bar mapped, nor mailbox command.
The FPGA is indeed a bump-on-the-wire.
(It has I2C to the CX4 chip, but that is for debug purposes, and too slow
to perform real programming)
The FPGA is programmed with RoCE packets. We are going to share a lot of
details about this in the IPSec offload patchset, so I don't want to
repeat it here.
In short, we open a RoCEv2 QP between the connect and the FPGA chips.
Over this QP, we can communicate at high speed with the FPGA.
> Is this FPGA expected to be customer programmable? In that case you
> really need the full infrastructure to bind the right driver (possibly
> a customer driver) to the current FPGA, to expose the correct
> operational interface to the kernel.
Most of the Innova family of cards are not customer-programmable.
Over time, they may require an upgrade (essentially a FW upgrade) but not
with customer logic.
One flavor of the product, the Innova Flex, allows customer logic in the
FPGA. But even then it is "wrapped" by Mellanox shell logic.
We plan to have an in-kernel API for writing client drivers for Innova
Flex.
>
> Jason
^ permalink raw reply
* RE: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
From: Ilan Tayari @ 2017-05-28 7:24 UTC (permalink / raw)
To: Jes Sorensen, Saeed Mahameed
Cc: Alexei Starovoitov, Saeed Mahameed, David S. Miller, Doug Ledford,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org
In-Reply-To: <f47d7519-4f58-bc94-2387-20342afd91b8@fb.com>
> -----Original Message-----
> From: Jes Sorensen [mailto:jsorensen@fb.com]
>
> On 05/26/2017 04:29 AM, Saeed Mahameed wrote:
> > On Thu, May 25, 2017 at 11:48 PM, Jes Sorensen <jsorensen@fb.com> wrote:
> >> On 05/25/2017 06:40 AM, Saeed Mahameed wrote:
> > Hi Jes,
> >
> > No, It is clearly stated in the commit message :
> >
> > "The FPGA is a bump-on-the-wire and thus affects operation of
> > the mlx5_core driver on the ConnectX ASIC."
> >
> > Which means mlx5 FPGA user can only write logic which affects only
> > packets going in/out
> > A ConnectX chip - so it is only network stuff -.
> >
> >> We have this with other devices in the kernel where a primary device
> driver
> >> provides an interface for an additional sub-driver to access another
> device
> >> behind it. Like bt-coexist in some of the wifi drivers allowing access
> to a
> >> bluetooth device behind it.
> >
> > Blutooth over wifi or vise versa is a very good example to what you
> > are requesting.
> > But, it doesn't fit to what we are trying to do here. mlx5 FGPA is a
> > ConnectX card feature, not a new protocol.
>
> In that case it would need to be an optional module that can be enabled
> or disabled at build time.
Jes,
It is already modular like that. See CONFIG_MLX5_FPGA.
Ilan.
>
> Cheers,
> Jes
>
^ permalink raw reply
* Re: [patch net-next 0/9] mlxsw: Support firmware flash
From: Yotam Gigi @ 2017-05-28 7:26 UTC (permalink / raw)
To: David Miller; +Cc: Yuval.Mintz, jiri, netdev, idosch, mlxsw, bhutchings
In-Reply-To: <20170523.113859.1803057381093280239.davem@davemloft.net>
On 05/23/2017 06:38 PM, David Miller wrote:
> From: Yotam Gigi <yotamg@mellanox.com>
> Date: Tue, 23 May 2017 18:14:15 +0300
>
>> Sorry, I am not sure I understand. You think that drivers should not implement
>> ethtool's flash_device callback anymore? do you have an alternative for firmware
>> flash?
> As stated, export an MTD device.
So, after we have been going over MTD, it seems like it does not fit our needs
at all.
MTD device provides (erasable-)block access to a flash storage, where in our
case the firmware burn process is just pouring a binary BLOB into the device.
The driver is not aware of the internal storage used for storing the firmware as
it is not defined in our driver-hardware API.
Needless to say that block access has no meaning in our case, so any solution
that will involve MTD device to burn our firmware (if there is a solution at
all) will be a workaround and will not fit MTD purpose.
Apart for boot time firmware flash, which we have already pushed we would really
like to allow the user to ask for a specific firmware version. Do you have any
other solution for us apart from "ethtool -f"?
This problem is even more relevant in the Mellanox HCA driver team, which would
like to use that code in order to burn the HCA firmware, but not intend to
trigger it on boot time, which means that must have a way for the user to
trigger it.
^ permalink raw reply
* Fwd: running an eBPF program
From: Adel Fuchs @ 2017-05-28 7:40 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAErYV9HhBoWnMVZS4XBJPN0TM4V2=U2Y+NBSyY8bqHJopvWTGA@mail.gmail.com>
Hi,
Is there any way to run this eBPF program without that patch?
Alternatively, is there any other eBPF sample that does run properly?
I need to run a program that filters packets according to IP address
or port.
Thanks,
Adel
On Sun, May 28, 2017 at 8:08 AM, Y Song <ys114321@gmail.com> wrote:
> On Sat, May 27, 2017 at 5:11 PM, David Miller <davem@davemloft.net> wrote:
>> From: Y Song <ys114321@gmail.com>
>> Date: Sat, 27 May 2017 13:52:27 -0700
>>
>>> On Sat, May 27, 2017 at 1:23 PM, Y Song <ys114321@gmail.com> wrote:
>>>>
>>>> From verifier error message:
>>>> ======
>>>> 0: (bf) r6 = r1
>>>>
>>>> 1: (18) r9 = 0xffe0000e
>>>>
>>>> 3: (69) r0 = *(u16 *)(r6 +16)
>>>>
>>>> invalid bpf_context access off=16 size=2
>>>> ======
>>>>
>>>> The offset 16 of struct __sk_buff is hash.
>>>> What instruction #3 tries to do is to access 2 bytes of the hash value
>>>> instead of full 4 bytes.
>>>> This is explicitly not allowed in verifier due to endianness issue.
>>>
>>>
>>> I can reproduce the issue now. My previous statement saying to access
>>> "hash" field is not correct. It is accessing the protocol field.
>>>
>>> static __inline__ bool flow_dissector(struct __sk_buff *skb,
>>> struct flow_keys *flow)
>>> {
>>> int poff, nh_off = BPF_LL_OFF + ETH_HLEN;
>>> __be16 proto = skb->protocol;
>>> __u8 ip_proto;
>>>
>>> The plan so far is to see whether we can fix the issue in LLVM side.
>>
>> If the compiler properly asks for "__sk_buff + 16" on little-endian
>> and "__sk_buff + 20" on big-endian, the verifier should instead be
>> fixed to allow the access to pass.
>>
>> I can't see any reason why LLVM won't set the offset properly like
>> that, and it's a completely legitimate optimization that we shouldn't
>> try to stop LLVM from performing.
>
> I do agree that such optimization in LLVM is perfect fine and actually
> beneficial.
> The only reason I was thinking was to avoid introduce endianness into verifier.
> Maybe not too much work there. Let me do some experiments and come with
> a patch for that.
>
> Thanks!
>
> Yonghong
>
>>
>> It also makes it so that we don't have to fix having absurdly defined
>> __sk_buff's protocol field as a u32.
>>
>> Thanks.
^ permalink raw reply
* vxlan: use after free error
From: Mark Bloch @ 2017-05-28 10:49 UTC (permalink / raw)
To: davem, jbenc, roopa, pshelar, aduyck, nicolas.dichtel; +Cc: netdev
Hi,
I'm getting a KASAN (use after free) error when doing:
ip link add vxlan1 type vxlan external
ip link set vxlan1 up
ip link set vxlan1 down
ip link del vxlan1
[ 600.495331] ==================================================================
[ 600.509678] BUG: KASAN: use-after-free in vxlan_dellink+0x33d/0x390 [vxlan]
[ 600.523083] Write of size 8 at addr ffff88056ce54018 by task ip/16216
[ 600.542239] CPU: 12 PID: 16216 Comm: ip Not tainted 4.12.0-rc2 #24
[ 600.554442] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/02/2014
[ 600.567013] Call Trace:
[ 600.574742] dump_stack+0x63/0x89
[ 600.583458] print_address_description+0x78/0x290
[ 600.593612] kasan_report+0x257/0x370
[ 600.602857] ? vxlan_dellink+0x33d/0x390 [vxlan]
[ 600.612765] __asan_report_store8_noabort+0x1c/0x20
[ 600.622937] vxlan_dellink+0x33d/0x390 [vxlan]
[ 600.632636] rtnl_delete_link+0xb9/0x110
[ 600.641542] ? rtnl_af_register+0xc0/0xc0
[ 600.650898] ? nla_parse+0x36/0x260
[ 600.659558] rtnl_dellink+0x1fb/0x780
[ 600.668350] ? unwind_dump+0x360/0x360
[ 600.676802] ? rtnl_bridge_getlink+0x620/0x620
[ 600.686036] ? __module_text_address+0x18/0x150
[ 600.695300] ? ns_capable_common+0xd4/0x110
[ 600.704157] ? sock_sendmsg+0xba/0xf0
[ 600.712264] ? ns_capable+0x13/0x20
[ 600.720201] ? __netlink_ns_capable+0xcc/0x100
[ 600.729131] rtnetlink_rcv_msg+0x255/0x6c0
[ 600.737464] ? rtnl_newlink+0x1640/0x1640
[ 600.745604] ? __read_once_size_nocheck.constprop.7+0x20/0x20
[ 600.755882] ? __read_once_size_nocheck.constprop.7+0x20/0x20
[ 600.765963] ? memset+0x31/0x40
[ 600.772985] netlink_rcv_skb+0x2de/0x460
[ 600.780829] ? rtnl_newlink+0x1640/0x1640
[ 600.788755] ? netlink_ack+0xaf0/0xaf0
[ 600.796181] ? __kmalloc_node_track_caller+0x205/0x2d0
[ 600.805370] ? __alloc_skb+0xdd/0x580
[ 600.812646] rtnetlink_rcv+0x28/0x30
[ 600.819882] netlink_unicast+0x430/0x620
[ 600.827433] ? netlink_attachskb+0x660/0x660
[ 600.835211] ? rw_copy_check_uvector+0x90/0x290
[ 600.843097] ? __module_text_address+0x18/0x150
[ 600.850985] netlink_sendmsg+0x7df/0xb90
[ 600.858105] ? netlink_unicast+0x620/0x620
[ 600.865493] ? kasan_alloc_pages+0x38/0x40
[ 600.873060] ? netlink_unicast+0x620/0x620
[ 600.880458] sock_sendmsg+0xba/0xf0
[ 600.886784] ___sys_sendmsg+0x6c9/0x8e0
[ 600.893300] ? copy_msghdr_from_user+0x520/0x520
[ 600.901017] ? memcg_write_event_control+0xd50/0xd50
[ 600.908938] ? __alloc_pages_slowpath+0x1ef0/0x1ef0
[ 600.916082] ? mem_cgroup_commit_charge+0xc4/0x1420
[ 600.923049] ? lru_cache_add_active_or_unevictable+0x7d/0x1a0
[ 600.931943] ? __handle_mm_fault+0x1bfe/0x2ba0
[ 600.939255] ? __pmd_alloc+0x240/0x240
[ 600.944767] __sys_sendmsg+0xce/0x160
[ 600.950154] ? __sys_sendmsg+0xce/0x160
[ 600.956030] ? SyS_shutdown+0x190/0x190
[ 600.962546] ? mntput+0x57/0x70
[ 600.968576] ? __fput+0x429/0x730
[ 600.973526] ? handle_mm_fault+0x28a/0x650
[ 600.979844] ? find_vma+0x1f/0x160
[ 600.985801] SyS_sendmsg+0x12/0x20
[ 600.991857] entry_SYSCALL_64_fastpath+0x1a/0xa5
[ 600.999044] RIP: 0033:0x7fe11cd80037
[ 601.005021] RSP: 002b:00007ffe0e7fc738 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[ 601.014890] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe11cd80037
[ 601.024808] RDX: 0000000000000000 RSI: 00007ffe0e7fc780 RDI: 0000000000000003
[ 601.035392] RBP: 00007ffe0e7fc780 R08: 0000000000000001 R09: fefefeff77686d74
[ 601.045517] R10: 00000000000005eb R11: 0000000000000246 R12: 00007ffe0e7fc7c0
[ 601.055590] R13: 0000000000669400 R14: 00007ffe0e804830 R15: 0000000000000000
[ 601.069998] The buggy address belongs to the page:
[ 601.078182] page:ffffea0015b39500 count:0 mapcount:-127 mapping: (null) index:0x0
[ 601.089760] flags: 0x2fffff80000000()
[ 601.096304] raw: 002fffff80000000 0000000000000000 0000000000000000 00000000ffffff80
[ 601.107417] raw: ffffea00156b2020 ffffea001836cb20 0000000000000002 0000000000000000
[ 601.118699] page dumped because: kasan: bad access detected
[ 601.131352] Memory state around the buggy address:
[ 601.139488] ffff88056ce53f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 601.149179] ffff88056ce53f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 601.159941] >ffff88056ce54000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 601.170313] ^
[ 601.176429] ffff88056ce54080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 601.187098] ffff88056ce54100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 601.196978] ==================================================================
The flow is something like this:
When we are upping the interface, we are calling vxlan_open() and after creating the
sockets (v4 & v6) we call vxlan_vs_add_dev() and add the vxlan device to each socket's list.
When we put down the interface, we call vxlan_stop() -> vxlan_sock_release() there
after calling __vxlan_sock_release_prep() we free each socket, the issue is that the vxlan
device is still part of each socket's list.
When we delete the vxlan interface, vxlan_dellink() is called and there we do:
hlist_del_rcu(&vxlan->hlist), which access already freed memory.
I'm not too familiar with the vxlan module, so to me a trivial fix like this makes sense.
Am I missing something?
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 328b471..7d57faf 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1058,6 +1058,7 @@ static bool __vxlan_sock_release_prep(struct vxlan_sock *vs)
static void vxlan_sock_release(struct vxlan_dev *vxlan)
{
struct vxlan_sock *sock4 = rtnl_dereference(vxlan->vn4_sock);
+ struct vxlan_net *vn = net_generic(vxlan->net, vxlan_net_id);
#if IS_ENABLED(CONFIG_IPV6)
struct vxlan_sock *sock6 = rtnl_dereference(vxlan->vn6_sock);
@@ -1067,6 +1068,10 @@ static void vxlan_sock_release(struct vxlan_dev *vxlan)
rcu_assign_pointer(vxlan->vn4_sock, NULL);
synchronize_net();
+ spin_lock(&vn->sock_lock);
+ hlist_del_rcu(&vxlan->hlist);
+ spin_unlock(&vn->sock_lock);
+
if (__vxlan_sock_release_prep(sock4)) {
udp_tunnel_sock_release(sock4->sock);
kfree(sock4);
@@ -3286,15 +3291,9 @@ static int vxlan_changelink(struct net_device *dev, struct nlattr *tb[],
static void vxlan_dellink(struct net_device *dev, struct list_head *head)
{
struct vxlan_dev *vxlan = netdev_priv(dev);
- struct vxlan_net *vn = net_generic(vxlan->net, vxlan_net_id);
vxlan_flush(vxlan, true);
- spin_lock(&vn->sock_lock);
- if (!hlist_unhashed(&vxlan->hlist))
- hlist_del_rcu(&vxlan->hlist);
- spin_unlock(&vn->sock_lock);
-
gro_cells_destroy(&vxlan->gro_cells);
list_del(&vxlan->next);
unregister_netdevice_queue(dev, head);
Mark
^ permalink raw reply related
* Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
From: Or Gerlitz @ 2017-05-28 12:33 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Saeed Mahameed, Ilan Tayari, David S. Miller, Doug Ledford,
netdev@vger.kernel.org, jsorensen@fb.com, Andy Shevchenko,
linux-fpga, Alan Tull, yi1.li
In-Reply-To: <20170526175624.5xxflpf24je5673h@ast-mbp>
On Fri, May 26, 2017 at 8:56 PM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Fri, May 26, 2017 at 11:59:26AM +0300, Saeed Mahameed wrote:
>> But i agree with you some serious API brainstorming should be
>> considered, but not at this stage, this patch only tells the ConnectX card
>> (if you have FPGA, please enable it).
> serious api discussion needs be done before things like eswitch, fpga
> exposed to users otherwise we end up in the eswitch situation that
> drops packets based on its own invisible logic, but with hidden fpga
> it will be even more obscure.
Alexei,
ACK for your comment on e-switch, what we call the legacy mode for SRIOV in
Linux was a big mistake.
As you know, since 4.8 we're @ MLNX are working to fix it... we introduced a
model for VF port representors which has set the foundations for
e-switch data-path
to be programmed as an offload for kernel SW switching. We also
introduced the code
to offload TC flower base data-path and support that in for both
switch (Spectrum) ASIC
(mlxsw driver) and NIC ASIC (mlx5 driver)
Or.
^ permalink raw reply
* GREETINGS BELOVED
From: mis.sborte09 @ 2017-05-28 13:34 UTC (permalink / raw)
GREETINGS BELOVED
I AM BORTE ,I WAS DIAGNOSE WITH OVARIAN CANCER,WHICH DOCTORS HAVE
CONFIRMED THAT I HAVE ONLY FEW WEEKS TO LIVE, SO I HAVE DECIDED TO
DONATE EVERYTHING I HAVE TO THE ORPHANAGE AND THE POOR WIDOWS THROUGH
YOU .PLEASE KINDLY REPLY ME ONLY ON MY EMAIL ADDRES HERE
(missboteogotai@gmail.com) AS SOON AS POSIBLE TO ENABLE ME GIVE YOU
MORE INFORMATION ABOUT MYSELF AND HOW TO GO ABOUT IT .
THANKS
MISS BORTE
^ permalink raw reply
* Error with printk and bpf_trace_printk
From: Adel Fuchs @ 2017-05-28 14:48 UTC (permalink / raw)
To: netdev
Hi,
I have a working eBPF program, and I'm trying to add outputs to it.
I'm not able to use both printk and bpf_trace_printk functions. I get
this error:
ELF contains non-map related relo data in entry 0 pointing to section
8! Compiler bug?!
Prog section 'ingress' rejected: Invalid argument (22)!
- Type: 3
- Instructions: 16 (0 over limit)
- License: GPL
Verifier analysis:
0: (bf) r6 = r1
1: (18) r1 = 0x0
3: (85) call bpf_unspec#0
unknown func bpf_unspec#0
Error fetching program/map!
Failed to retrieve (e)BPF data!
Are there certain "includes" that I need to add?
In addition, I'm not sure I'm using the function correctly. I just
wrote: printk("hi")
Thanks!
Adel
^ permalink raw reply
* RE: [PATCH net-next 02/12] nfp: set driver VF limit
From: Mintz, Yuval @ 2017-05-28 14:49 UTC (permalink / raw)
To: Jakub Kicinski, netdev@vger.kernel.org; +Cc: oss-drivers@netronome.com
In-Reply-To: <20170528003411.17603-3-jakub.kicinski@netronome.com>
> pf->limit_vfs = nfp_rtsym_read_le(pf->cpp, "nfd_vf_cfg_max_vfs",
> &err);
> if (!err)
> - return;
> + return pci_sriov_set_totalvfs(pf->pdev, pf->limit_vfs);
While you're at it, If you're going to enforce the limit at the PCI level,
shouldn't you retire 'limit_vfs' altogether?
BTW, under which conditions would you expect to find a difference
in the maximal number of VFs?
^ permalink raw reply
* [PATCH net-next 00/10] qed: DCBx and Attentions series
From: Yuval Mintz @ 2017-05-28 15:01 UTC (permalink / raw)
To: davem, netdev; +Cc: Yuval Mintz
The series contains 2 major components [& some odd bits]:
- The first 3 patches are DCBx-related, containg missing bits in the
implementation, correcting existing API and removing code no longer
necessary.
- Most of the remaining patches are interrupt/hw-attention related,
adding some differeneces relating to QL41xxx and QL45xxx differences.
While at it, they also remove a large chunk of unnecessary structure
definitions.
The series also contain a patch [#10] that was accidently missing
from a previous series.
Dave,
Please consider applying this series to `net-next'.
Thanks,
Yuval
Sudarsana Reddy Kalluru (3):
qed: Add missing static/local dcbx info
qed: Correct DCBx update scheme
qed: Don't inherit RoCE DCBx for V2
Yuval Mintz (7):
qed: QL41xxx VF MSI-x table
qed: Support dynamic s-tag change
qed: Get rid of the attention-arrays
qed: Diffrentiate adapter-specific attentions
qed: Print multi-bit attentions properly
qed: Mask parities after occurance
qed: Cache alignemnt padding to match host
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 30 +-
drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 2 +-
drivers/net/ethernet/qlogic/qed/qed_debug.c | 258 ++++
drivers/net/ethernet/qlogic/qed/qed_dev.c | 15 +-
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 44 +-
drivers/net/ethernet/qlogic/qed/qed_int.c | 1466 +++------------------
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 61 +-
drivers/net/ethernet/qlogic/qed/qed_reg_addr.h | 3 +
drivers/net/ethernet/qlogic/qed/qed_sp.h | 9 +
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c | 24 +
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 32 +-
11 files changed, 601 insertions(+), 1343 deletions(-)
--
1.9.3
^ permalink raw reply
* [PATCH net-next 01/10] qed: Add missing static/local dcbx info
From: Yuval Mintz @ 2017-05-28 15:01 UTC (permalink / raw)
To: davem, netdev; +Cc: Sudarsana Reddy Kalluru, Yuval Mintz
In-Reply-To: <1495983720-10853-1-git-send-email-Yuval.Mintz@cavium.com>
From: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Some getters are not getting filled with the correct information
regarding local DCBx.
Fixes: 49632b5822ea ("qed: Add support for static dcbx.")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index b83fe1d..efe309e 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -1460,7 +1460,7 @@ static u8 qed_dcbnl_getcap(struct qed_dev *cdev, int capid, u8 *cap)
break;
case DCB_CAP_ATTR_DCBX:
*cap = (DCB_CAP_DCBX_LLD_MANAGED | DCB_CAP_DCBX_VER_CEE |
- DCB_CAP_DCBX_VER_IEEE);
+ DCB_CAP_DCBX_VER_IEEE | DCB_CAP_DCBX_STATIC);
break;
default:
*cap = false;
@@ -1534,6 +1534,8 @@ static u8 qed_dcbnl_getdcbx(struct qed_dev *cdev)
mode |= DCB_CAP_DCBX_VER_IEEE;
if (dcbx_info->operational.cee)
mode |= DCB_CAP_DCBX_VER_CEE;
+ if (dcbx_info->operational.local)
+ mode |= DCB_CAP_DCBX_STATIC;
DP_VERBOSE(hwfn, QED_MSG_DCB, "dcb mode = %d\n", mode);
kfree(dcbx_info);
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 02/10] qed: Correct DCBx update scheme
From: Yuval Mintz @ 2017-05-28 15:01 UTC (permalink / raw)
To: davem, netdev; +Cc: Sudarsana Reddy Kalluru, Yuval Mintz
In-Reply-To: <1495983720-10853-1-git-send-email-Yuval.Mintz@cavium.com>
From: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Instead of using a boolean value that propagates to FW configuration,
use the proper firmware HSI values.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 15 ++++++++-------
drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 2 +-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index efe309e..af34638 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -191,17 +191,19 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
qed_dcbx_set_params(struct qed_dcbx_results *p_data,
struct qed_hw_info *p_info,
bool enable,
- bool update,
u8 prio,
u8 tc,
enum dcbx_protocol_type type,
enum qed_pci_personality personality)
{
/* PF update ramrod data */
- p_data->arr[type].update = update;
p_data->arr[type].enable = enable;
p_data->arr[type].priority = prio;
p_data->arr[type].tc = tc;
+ if (enable)
+ p_data->arr[type].update = UPDATE_DCB;
+ else
+ p_data->arr[type].update = DONT_UPDATE_DCB_DSCP;
/* QM reconf data */
if (p_info->personality == personality)
@@ -213,7 +215,6 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
qed_dcbx_update_app_info(struct qed_dcbx_results *p_data,
struct qed_hwfn *p_hwfn,
bool enable,
- bool update,
u8 prio, u8 tc, enum dcbx_protocol_type type)
{
struct qed_hw_info *p_info = &p_hwfn->hw_info;
@@ -231,7 +232,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
personality = qed_dcbx_app_update[i].personality;
name = qed_dcbx_app_update[i].name;
- qed_dcbx_set_params(p_data, p_info, enable, update,
+ qed_dcbx_set_params(p_data, p_info, enable,
prio, tc, type, personality);
}
}
@@ -304,7 +305,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
*/
enable = !(type == DCBX_PROTOCOL_ETH);
- qed_dcbx_update_app_info(p_data, p_hwfn, enable, true,
+ qed_dcbx_update_app_info(p_data, p_hwfn, enable,
priority, tc, type);
}
}
@@ -332,8 +333,8 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
if (p_data->arr[type].update)
continue;
- enable = !(type == DCBX_PROTOCOL_ETH);
- qed_dcbx_update_app_info(p_data, p_hwfn, enable, true,
+ enable = (type == DCBX_PROTOCOL_ETH) ? false : !!dcbx_version;
+ qed_dcbx_update_app_info(p_data, p_hwfn, enable,
priority, tc, type);
}
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.h b/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
index 414e262..5feb90e 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
@@ -52,7 +52,7 @@ enum qed_mib_read_type {
struct qed_dcbx_app_data {
bool enable; /* DCB enabled */
- bool update; /* Update indication */
+ u8 update; /* Update indication */
u8 priority; /* Priority */
u8 tc; /* Traffic Class */
};
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 03/10] qed: Don't inherit RoCE DCBx for V2
From: Yuval Mintz @ 2017-05-28 15:01 UTC (permalink / raw)
To: davem, netdev; +Cc: Sudarsana Reddy Kalluru, Yuval Mintz
In-Reply-To: <1495983720-10853-1-git-send-email-Yuval.Mintz@cavium.com>
From: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Older firmware used by device didn't distinguish between RoCE and RoCE
V2 from DCBx configuration perspective, and as a result we've used to
take a the RoCE-related configuration and apply to it for both.
Since we now support configuring each its own values, there's no reason
to reflect [& configure] that both are using the same.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index af34638..e2a62c0 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -310,17 +310,6 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
}
}
- /* If RoCE-V2 TLV is not detected, driver need to use RoCE app
- * data for RoCE-v2 not the default app data.
- */
- if (!p_data->arr[DCBX_PROTOCOL_ROCE_V2].update &&
- p_data->arr[DCBX_PROTOCOL_ROCE].update) {
- tc = p_data->arr[DCBX_PROTOCOL_ROCE].tc;
- priority = p_data->arr[DCBX_PROTOCOL_ROCE].priority;
- qed_dcbx_update_app_info(p_data, p_hwfn, true, true,
- priority, tc, DCBX_PROTOCOL_ROCE_V2);
- }
-
/* Update ramrod protocol data and hw_info fields
* with default info when corresponding APP TLV's are not detected.
* The enabled field has a different logic for ethernet as only for
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 04/10] qed: QL41xxx VF MSI-x table
From: Yuval Mintz @ 2017-05-28 15:01 UTC (permalink / raw)
To: davem, netdev; +Cc: Yuval Mintz
In-Reply-To: <1495983720-10853-1-git-send-email-Yuval.Mintz@cavium.com>
The QL41xxx adapters' PCI allows a single configuration for the
MSI-x table size of all child VFs of a given PF.
The existing code wouldn't cause the management firmware to set
that value, meaning the VFs would retain the default MSI-x table
size.
Introduce a new scheme so that whenever a VF is enabled, driver
would set the number of MSI-x to be the maximum over the various
VFs' needs.
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 3 ++-
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 35 +++++++++++++++++++++++++++--
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 32 +++++++++++++++++++++++++-
3 files changed, 66 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_hsi.h b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
index 802c162..f610e52 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_hsi.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
@@ -11477,6 +11477,7 @@ struct public_drv_mb {
#define DRV_MSG_CODE_INITIATE_PF_FLR 0x02010000
#define DRV_MSG_CODE_VF_DISABLED_DONE 0xc0000000
#define DRV_MSG_CODE_CFG_VF_MSIX 0xc0010000
+#define DRV_MSG_CODE_CFG_PF_VFS_MSIX 0xc0020000
#define DRV_MSG_CODE_NVM_GET_FILE_ATT 0x00030000
#define DRV_MSG_CODE_NVM_READ_NVRAM 0x00050000
#define DRV_MSG_CODE_MCP_RESET 0x00090000
@@ -11640,7 +11641,7 @@ struct public_drv_mb {
#define FW_MSG_CODE_OS_WOL_SUPPORTED 0x00800000
#define FW_MSG_CODE_OS_WOL_NOT_SUPPORTED 0x00810000
-
+#define FW_MSG_CODE_DRV_CFG_PF_VFS_MSIX_DONE 0x00870000
#define FW_MSG_SEQ_NUMBER_MASK 0x0000ffff
u32 fw_mb_param;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index fc49c75e..24c9b71 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -1801,8 +1801,9 @@ int qed_mcp_get_flash_size(struct qed_hwfn *p_hwfn,
return 0;
}
-int qed_mcp_config_vf_msix(struct qed_hwfn *p_hwfn,
- struct qed_ptt *p_ptt, u8 vf_id, u8 num)
+static int
+qed_mcp_config_vf_msix_bb(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt, u8 vf_id, u8 num)
{
u32 resp = 0, param = 0, rc_param = 0;
int rc;
@@ -1832,6 +1833,36 @@ int qed_mcp_config_vf_msix(struct qed_hwfn *p_hwfn,
return rc;
}
+static int
+qed_mcp_config_vf_msix_ah(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt, u8 num)
+{
+ u32 resp = 0, param = num, rc_param = 0;
+ int rc;
+
+ rc = qed_mcp_cmd(p_hwfn, p_ptt, DRV_MSG_CODE_CFG_PF_VFS_MSIX,
+ param, &resp, &rc_param);
+
+ if (resp != FW_MSG_CODE_DRV_CFG_PF_VFS_MSIX_DONE) {
+ DP_NOTICE(p_hwfn, "MFW failed to set MSI-X for VFs\n");
+ rc = -EINVAL;
+ } else {
+ DP_VERBOSE(p_hwfn, QED_MSG_IOV,
+ "Requested 0x%02x MSI-x interrupts for VFs\n", num);
+ }
+
+ return rc;
+}
+
+int qed_mcp_config_vf_msix(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt, u8 vf_id, u8 num)
+{
+ if (QED_IS_BB(p_hwfn->cdev))
+ return qed_mcp_config_vf_msix_bb(p_hwfn, p_ptt, vf_id, num);
+ else
+ return qed_mcp_config_vf_msix_ah(p_hwfn, p_ptt, num);
+}
+
int
qed_mcp_send_drv_version(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index 71e392f..b6bda45d 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -747,6 +747,35 @@ static void qed_iov_vf_igu_set_int(struct qed_hwfn *p_hwfn,
qed_fid_pretend(p_hwfn, p_ptt, (u16) p_hwfn->hw_info.concrete_fid);
}
+static int
+qed_iov_enable_vf_access_msix(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt, u8 abs_vf_id, u8 num_sbs)
+{
+ u8 current_max = 0;
+ int i;
+
+ /* For AH onward, configuration is per-PF. Find maximum of all
+ * the currently enabled child VFs, and set the number to be that.
+ */
+ if (!QED_IS_BB(p_hwfn->cdev)) {
+ qed_for_each_vf(p_hwfn, i) {
+ struct qed_vf_info *p_vf;
+
+ p_vf = qed_iov_get_vf_info(p_hwfn, (u16)i, true);
+ if (!p_vf)
+ continue;
+
+ current_max = max_t(u8, current_max, p_vf->num_sbs);
+ }
+ }
+
+ if (num_sbs > current_max)
+ return qed_mcp_config_vf_msix(p_hwfn, p_ptt,
+ abs_vf_id, num_sbs);
+
+ return 0;
+}
+
static int qed_iov_enable_vf_access(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt,
struct qed_vf_info *vf)
@@ -771,7 +800,8 @@ static int qed_iov_enable_vf_access(struct qed_hwfn *p_hwfn,
qed_iov_vf_igu_reset(p_hwfn, p_ptt, vf);
- rc = qed_mcp_config_vf_msix(p_hwfn, p_ptt, vf->abs_vf_id, vf->num_sbs);
+ rc = qed_iov_enable_vf_access_msix(p_hwfn, p_ptt,
+ vf->abs_vf_id, vf->num_sbs);
if (rc)
return rc;
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 05/10] qed: Support dynamic s-tag change
From: Yuval Mintz @ 2017-05-28 15:01 UTC (permalink / raw)
To: davem, netdev; +Cc: Yuval Mintz
In-Reply-To: <1495983720-10853-1-git-send-email-Yuval.Mintz@cavium.com>
In case management firmware indicates a change in the used S-tag,
propagate the configuration to HW and FW.
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 4 +++-
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 26 +++++++++++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_reg_addr.h | 2 ++
drivers/net/ethernet/qlogic/qed/qed_sp.h | 9 ++++++++
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c | 24 +++++++++++++++++++++
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_hsi.h b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
index f610e52..24b1458 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_hsi.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
@@ -11474,6 +11474,7 @@ struct public_drv_mb {
#define DRV_MSG_CODE_BW_UPDATE_ACK 0x32000000
#define DRV_MSG_CODE_NIG_DRAIN 0x30000000
+#define DRV_MSG_CODE_S_TAG_UPDATE_ACK 0x3b000000
#define DRV_MSG_CODE_INITIATE_PF_FLR 0x02010000
#define DRV_MSG_CODE_VF_DISABLED_DONE 0xc0000000
#define DRV_MSG_CODE_CFG_VF_MSIX 0xc0010000
@@ -11634,6 +11635,7 @@ struct public_drv_mb {
#define FW_MSG_CODE_RESOURCE_ALLOC_OK 0x34000000
#define FW_MSG_CODE_RESOURCE_ALLOC_UNKNOWN 0x35000000
#define FW_MSG_CODE_RESOURCE_ALLOC_DEPRECATED 0x36000000
+#define FW_MSG_CODE_S_TAG_UPDATE_ACK_DONE 0x3b000000
#define FW_MSG_CODE_DRV_CFG_VF_MSIX_DONE 0xb0010000
#define FW_MSG_CODE_NVM_OK 0x00010000
@@ -11681,7 +11683,7 @@ enum MFW_DRV_MSG_TYPE {
MFW_DRV_MSG_DCBX_OPERATIONAL_MIB_UPDATED,
MFW_DRV_MSG_RESERVED4,
MFW_DRV_MSG_BW_UPDATE,
- MFW_DRV_MSG_BW_UPDATE5,
+ MFW_DRV_MSG_S_TAG_UPDATE,
MFW_DRV_MSG_GET_LAN_STATS,
MFW_DRV_MSG_GET_FCOE_STATS,
MFW_DRV_MSG_GET_ISCSI_STATS,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 24c9b71..31c88e1 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -1398,6 +1398,28 @@ static void qed_mcp_update_bw(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
¶m);
}
+static void qed_mcp_update_stag(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
+{
+ struct public_func shmem_info;
+ u32 resp = 0, param = 0;
+
+ qed_mcp_get_shmem_func(p_hwfn, p_ptt, &shmem_info, MCP_PF_ID(p_hwfn));
+
+ p_hwfn->mcp_info->func_info.ovlan = (u16)shmem_info.ovlan_stag &
+ FUNC_MF_CFG_OV_STAG_MASK;
+ p_hwfn->hw_info.ovlan = p_hwfn->mcp_info->func_info.ovlan;
+ if ((p_hwfn->hw_info.hw_mode & BIT(MODE_MF_SD)) &&
+ (p_hwfn->hw_info.ovlan != QED_MCP_VLAN_UNSET)) {
+ qed_wr(p_hwfn, p_ptt,
+ NIG_REG_LLH_FUNC_TAG_VALUE, p_hwfn->hw_info.ovlan);
+ qed_sp_pf_update_stag(p_hwfn);
+ }
+
+ /* Acknowledge the MFW */
+ qed_mcp_cmd(p_hwfn, p_ptt, DRV_MSG_CODE_S_TAG_UPDATE_ACK, 0,
+ &resp, ¶m);
+}
+
int qed_mcp_handle_events(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt)
{
@@ -1453,6 +1475,10 @@ int qed_mcp_handle_events(struct qed_hwfn *p_hwfn,
case MFW_DRV_MSG_BW_UPDATE:
qed_mcp_update_bw(p_hwfn, p_ptt);
break;
+ case MFW_DRV_MSG_S_TAG_UPDATE:
+ qed_mcp_update_stag(p_hwfn, p_ptt);
+ break;
+ break;
default:
DP_INFO(p_hwfn, "Unimplemented MFW message %d\n", i);
rc = -EINVAL;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_reg_addr.h b/drivers/net/ethernet/qlogic/qed/qed_reg_addr.h
index f14772b..6abf918 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_reg_addr.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_reg_addr.h
@@ -242,6 +242,8 @@
0x50196cUL
#define NIG_REG_LLH_CLS_TYPE_DUALMODE \
0x501964UL
+#define NIG_REG_LLH_FUNC_TAG_EN 0x5019b0UL
+#define NIG_REG_LLH_FUNC_TAG_VALUE 0x5019d0UL
#define NIG_REG_LLH_FUNC_FILTER_VALUE \
0x501a00UL
#define NIG_REG_LLH_FUNC_FILTER_VALUE_SIZE \
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sp.h b/drivers/net/ethernet/qlogic/qed/qed_sp.h
index ef77de4..b9464f3 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sp.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_sp.h
@@ -418,6 +418,15 @@ int qed_sp_pf_start(struct qed_hwfn *p_hwfn,
int qed_sp_pf_update(struct qed_hwfn *p_hwfn);
/**
+ * @brief qed_sp_pf_update_stag - Update firmware of new outer tag
+ *
+ * @param p_hwfn
+ *
+ * @return int
+ */
+int qed_sp_pf_update_stag(struct qed_hwfn *p_hwfn);
+
+/**
* @brief qed_sp_pf_stop - PF Function Stop Ramrod
*
* This ramrod is sent to close a Physical Function (PF). It is the last ramrod
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c b/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c
index ab09975..46d0c3c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c
@@ -514,3 +514,27 @@ int qed_sp_heartbeat_ramrod(struct qed_hwfn *p_hwfn)
return qed_spq_post(p_hwfn, p_ent, NULL);
}
+
+int qed_sp_pf_update_stag(struct qed_hwfn *p_hwfn)
+{
+ struct qed_spq_entry *p_ent = NULL;
+ struct qed_sp_init_data init_data;
+ int rc = -EINVAL;
+
+ /* Get SPQ entry */
+ memset(&init_data, 0, sizeof(init_data));
+ init_data.cid = qed_spq_get_cid(p_hwfn);
+ init_data.opaque_fid = p_hwfn->hw_info.opaque_fid;
+ init_data.comp_mode = QED_SPQ_MODE_CB;
+
+ rc = qed_sp_init_request(p_hwfn, &p_ent,
+ COMMON_RAMROD_PF_UPDATE, PROTOCOLID_COMMON,
+ &init_data);
+ if (rc)
+ return rc;
+
+ p_ent->ramrod.pf_update.update_mf_vlan_flag = true;
+ p_ent->ramrod.pf_update.mf_vlan = cpu_to_le16(p_hwfn->hw_info.ovlan);
+
+ return qed_spq_post(p_hwfn, p_ent, NULL);
+}
--
1.9.3
^ 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