* [net-next 07/17] i40e: group base mode VF offload flags
From: Jeff Kirsher @ 2016-10-29 7:30 UTC (permalink / raw)
To: davem
Cc: Preethi Banala, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1477726258-111563-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Preethi Banala <preethi.banala@intel.com>
Group together the minimum set of offload capabilities that are always
supported by VF in base mode. This define would be used by PF to make
sure VF in base mode gets minimum of base capabilities .
Change-ID: Id5e8f22ba169c8f0a38d22fc36b2cb531c02582c
Signed-off-by: Preethi Banala <preethi.banala@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl.h | 4 ++++
drivers/net/ethernet/intel/i40evf/i40e_virtchnl.h | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl.h b/drivers/net/ethernet/intel/i40e/i40e_virtchnl.h
index f861d31..974ba2b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl.h
@@ -165,6 +165,10 @@ struct i40e_virtchnl_vsi_resource {
#define I40E_VIRTCHNL_VF_OFFLOAD_RSS_PF 0X00080000
#define I40E_VIRTCHNL_VF_OFFLOAD_ENCAP_CSUM 0X00100000
+#define I40E_VF_BASE_MODE_OFFLOADS (I40E_VIRTCHNL_VF_OFFLOAD_L2 | \
+ I40E_VIRTCHNL_VF_OFFLOAD_VLAN | \
+ I40E_VIRTCHNL_VF_OFFLOAD_RSS_PF)
+
struct i40e_virtchnl_vf_resource {
u16 num_vsis;
u16 num_queue_pairs;
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_virtchnl.h b/drivers/net/ethernet/intel/i40evf/i40e_virtchnl.h
index bd691ad..fc374f8 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_virtchnl.h
+++ b/drivers/net/ethernet/intel/i40evf/i40e_virtchnl.h
@@ -162,6 +162,10 @@ struct i40e_virtchnl_vsi_resource {
#define I40E_VIRTCHNL_VF_OFFLOAD_RSS_PF 0X00080000
#define I40E_VIRTCHNL_VF_OFFLOAD_ENCAP_CSUM 0X00100000
+#define I40E_VF_BASE_MODE_OFFLOADS (I40E_VIRTCHNL_VF_OFFLOAD_L2 | \
+ I40E_VIRTCHNL_VF_OFFLOAD_VLAN | \
+ I40E_VIRTCHNL_VF_OFFLOAD_RSS_PF)
+
struct i40e_virtchnl_vf_resource {
u16 num_vsis;
u16 num_queue_pairs;
--
2.7.4
^ permalink raw reply related
* [net-next 10/17] i40e: Make struct i40e_stats const
From: Jeff Kirsher @ 2016-10-29 7:30 UTC (permalink / raw)
To: davem
Cc: Joe Perches, netdev, nhorman, sassmann, jogreene, guru.anbalagane,
Jeff Kirsher
In-Reply-To: <1477726258-111563-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Joe Perches <joe@perches.com>
Move some data to text
$ size drivers/net/ethernet/intel/i40e/i40e_ethtool.o*
text data bss dec hex filename
25012 0 32 25044 61d4 drivers/net/ethernet/intel/i40e/i40e_ethtool.o.new
22868 2120 32 25020 61bc drivers/net/ethernet/intel/i40e/i40e_ethtool.o.old
Signed-off-by: Joe Perches <joe@perches.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 92bc884..3a1f91e 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -104,7 +104,7 @@ static const struct i40e_stats i40e_gstrings_misc_stats[] = {
* The PF_STATs are appended to the netdev stats only when ethtool -S
* is queried on the base PF netdev, not on the VMDq or FCoE netdev.
*/
-static struct i40e_stats i40e_gstrings_stats[] = {
+static const struct i40e_stats i40e_gstrings_stats[] = {
I40E_PF_STAT("rx_bytes", stats.eth.rx_bytes),
I40E_PF_STAT("tx_bytes", stats.eth.tx_bytes),
I40E_PF_STAT("rx_unicast", stats.eth.rx_unicast),
--
2.7.4
^ permalink raw reply related
* [net-next 16/17] i40e: Fix bit logic error in failure case
From: Jeff Kirsher @ 2016-10-29 7:30 UTC (permalink / raw)
To: davem
Cc: David Ertman, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1477726258-111563-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: David Ertman <david.m.ertman@intel.com>
Patch a036244c0686 "i40e: Fix kernel panic on enable/disable LLDP"
introduced an error in bit logic.
Originally this bit manipulation was meant to clear two bits to indicate
that DCB was not enabled or capable. An "&" was incorrectly used instead
of an "|" bit operator to combine the two bitmasks into one. This also
created a static checker error since the resultant code was a no-op.
This patch fixes the error by using the correct bit-wise operator.
Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 00c322d..0c2328d 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -10970,7 +10970,7 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
err = i40e_init_pf_dcb(pf);
if (err) {
dev_info(&pdev->dev, "DCB init failed %d, disabled\n", err);
- pf->flags &= ~(I40E_FLAG_DCB_CAPABLE & I40E_FLAG_DCB_ENABLED);
+ pf->flags &= ~(I40E_FLAG_DCB_CAPABLE | I40E_FLAG_DCB_ENABLED);
/* Continue without DCB enabled */
}
#endif /* CONFIG_I40E_DCB */
--
2.7.4
^ permalink raw reply related
* [net-next 12/17] i40e: Drop redundant Rx descriptor processing code
From: Jeff Kirsher @ 2016-10-29 7:30 UTC (permalink / raw)
To: davem
Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1477726258-111563-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch cleans up several pieces of redundant code in the Rx clean-up
paths.
The first bit is that hdr_addr and the status_err_len portions of the Rx
descriptor represent the same value. As such there is no point in setting
them to 0 before setting them to 0. I'm dropping the second spot where we
are updating the value to 0 so that we only have 1 write for this value
instead of 2.
The second piece is the checking for the DD bit in the packet. We only
need to check for a non-zero value for the status_err_len because if the
device is done with the descriptor it will have written something back and
the DD is just one piece of it. In addition I have moved the reading of
the Rx descriptor bits related to rx_ptype down so that they are actually
below the dma_rmb() call so that we are guaranteed that we don't have any
funky 64b on 32b calls causing any ordering issues.
Change-ID: I256e44a025d3c64a7224aaaec37c852bfcb1871b
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 18 ++++++------------
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 18 ++++++------------
2 files changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 48e6533..daade4fe 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -1220,7 +1220,6 @@ bool i40e_alloc_rx_buffers(struct i40e_ring *rx_ring, u16 cleaned_count)
* because each write-back erases this info.
*/
rx_desc->read.pkt_addr = cpu_to_le64(bi->dma + bi->page_offset);
- rx_desc->read.hdr_addr = 0;
rx_desc++;
bi++;
@@ -1741,7 +1740,6 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget)
while (likely(total_rx_packets < budget)) {
union i40e_rx_desc *rx_desc;
struct sk_buff *skb;
- u32 rx_status;
u16 vlan_tag;
u8 rx_ptype;
u64 qword;
@@ -1755,21 +1753,13 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget)
rx_desc = I40E_RX_DESC(rx_ring, rx_ring->next_to_clean);
- qword = le64_to_cpu(rx_desc->wb.qword1.status_error_len);
- rx_ptype = (qword & I40E_RXD_QW1_PTYPE_MASK) >>
- I40E_RXD_QW1_PTYPE_SHIFT;
- rx_status = (qword & I40E_RXD_QW1_STATUS_MASK) >>
- I40E_RXD_QW1_STATUS_SHIFT;
-
- if (!(rx_status & BIT(I40E_RX_DESC_STATUS_DD_SHIFT)))
- break;
-
/* status_error_len will always be zero for unused descriptors
* because it's cleared in cleanup, and overlaps with hdr_addr
* which is always zero because packet split isn't used, if the
* hardware wrote DD then it will be non-zero
*/
- if (!rx_desc->wb.qword1.status_error_len)
+ if (!i40e_test_staterr(rx_desc,
+ BIT(I40E_RX_DESC_STATUS_DD_SHIFT)))
break;
/* This memory barrier is needed to keep us from reading
@@ -1803,6 +1793,10 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget)
/* probably a little skewed due to removing CRC */
total_rx_bytes += skb->len;
+ qword = le64_to_cpu(rx_desc->wb.qword1.status_error_len);
+ rx_ptype = (qword & I40E_RXD_QW1_PTYPE_MASK) >>
+ I40E_RXD_QW1_PTYPE_SHIFT;
+
/* populate checksum, VLAN, and protocol */
i40e_process_skb_fields(rx_ring, rx_desc, skb, rx_ptype);
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
index dd8ad6b..e2d3622 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
@@ -705,7 +705,6 @@ bool i40evf_alloc_rx_buffers(struct i40e_ring *rx_ring, u16 cleaned_count)
* because each write-back erases this info.
*/
rx_desc->read.pkt_addr = cpu_to_le64(bi->dma + bi->page_offset);
- rx_desc->read.hdr_addr = 0;
rx_desc++;
bi++;
@@ -1209,7 +1208,6 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget)
while (likely(total_rx_packets < budget)) {
union i40e_rx_desc *rx_desc;
struct sk_buff *skb;
- u32 rx_status;
u16 vlan_tag;
u8 rx_ptype;
u64 qword;
@@ -1223,21 +1221,13 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget)
rx_desc = I40E_RX_DESC(rx_ring, rx_ring->next_to_clean);
- qword = le64_to_cpu(rx_desc->wb.qword1.status_error_len);
- rx_ptype = (qword & I40E_RXD_QW1_PTYPE_MASK) >>
- I40E_RXD_QW1_PTYPE_SHIFT;
- rx_status = (qword & I40E_RXD_QW1_STATUS_MASK) >>
- I40E_RXD_QW1_STATUS_SHIFT;
-
- if (!(rx_status & BIT(I40E_RX_DESC_STATUS_DD_SHIFT)))
- break;
-
/* status_error_len will always be zero for unused descriptors
* because it's cleared in cleanup, and overlaps with hdr_addr
* which is always zero because packet split isn't used, if the
* hardware wrote DD then it will be non-zero
*/
- if (!rx_desc->wb.qword1.status_error_len)
+ if (!i40e_test_staterr(rx_desc,
+ BIT(I40E_RX_DESC_STATUS_DD_SHIFT)))
break;
/* This memory barrier is needed to keep us from reading
@@ -1271,6 +1261,10 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget)
/* probably a little skewed due to removing CRC */
total_rx_bytes += skb->len;
+ qword = le64_to_cpu(rx_desc->wb.qword1.status_error_len);
+ rx_ptype = (qword & I40E_RXD_QW1_PTYPE_MASK) >>
+ I40E_RXD_QW1_PTYPE_SHIFT;
+
/* populate checksum, VLAN, and protocol */
i40evf_process_skb_fields(rx_ring, rx_desc, skb, rx_ptype);
--
2.7.4
^ permalink raw reply related
* [net-next 09/17] i40e/i40evf: Changed version from 1.6.16 to 1.6.19
From: Jeff Kirsher @ 2016-10-29 7:30 UTC (permalink / raw)
To: davem
Cc: Bimmy Pujari, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1477726258-111563-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Bimmy Pujari <bimmy.pujari@intel.com>
Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 9382ba80..c25247f 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -41,7 +41,7 @@ static const char i40e_driver_string[] =
#define DRV_VERSION_MAJOR 1
#define DRV_VERSION_MINOR 6
-#define DRV_VERSION_BUILD 16
+#define DRV_VERSION_BUILD 19
#define DRV_VERSION __stringify(DRV_VERSION_MAJOR) "." \
__stringify(DRV_VERSION_MINOR) "." \
__stringify(DRV_VERSION_BUILD) DRV_KERN
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index e95e873..3e51ff2 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -38,7 +38,7 @@ static const char i40evf_driver_string[] =
#define DRV_VERSION_MAJOR 1
#define DRV_VERSION_MINOR 6
-#define DRV_VERSION_BUILD 16
+#define DRV_VERSION_BUILD 19
#define DRV_VERSION __stringify(DRV_VERSION_MAJOR) "." \
__stringify(DRV_VERSION_MINOR) "." \
__stringify(DRV_VERSION_BUILD) \
--
2.7.4
^ permalink raw reply related
* [net-next 15/17] i40e/i40evf: Changed version from 1.6.19 to 1.6.21
From: Jeff Kirsher @ 2016-10-29 7:30 UTC (permalink / raw)
To: davem
Cc: Bimmy Pujari, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1477726258-111563-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Bimmy Pujari <bimmy.pujari@intel.com>
Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 2e787ff..00c322d 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -41,7 +41,7 @@ static const char i40e_driver_string[] =
#define DRV_VERSION_MAJOR 1
#define DRV_VERSION_MINOR 6
-#define DRV_VERSION_BUILD 19
+#define DRV_VERSION_BUILD 21
#define DRV_VERSION __stringify(DRV_VERSION_MAJOR) "." \
__stringify(DRV_VERSION_MINOR) "." \
__stringify(DRV_VERSION_BUILD) DRV_KERN
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 3e51ff2..bcb1caf 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -38,7 +38,7 @@ static const char i40evf_driver_string[] =
#define DRV_VERSION_MAJOR 1
#define DRV_VERSION_MINOR 6
-#define DRV_VERSION_BUILD 19
+#define DRV_VERSION_BUILD 21
#define DRV_VERSION __stringify(DRV_VERSION_MAJOR) "." \
__stringify(DRV_VERSION_MINOR) "." \
__stringify(DRV_VERSION_BUILD) \
--
2.7.4
^ permalink raw reply related
* [net-next 17/17] i40e: Clean up handling of msglevel flags and debug parameter
From: Jeff Kirsher @ 2016-10-29 7:30 UTC (permalink / raw)
To: davem
Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1477726258-111563-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
So the i40e driver had a really convoluted configuration for how to handle
the debug flags contained in msg_level. Part of the issue is that the
driver has its own 32 bit mask that it was using to track a separate set of
debug features. From what I can tell it was trying to use the upper 4 bits
to determine if the value was meant to represent a bit-mask or the numeric
value provided by debug level.
What this patch does is clean this up by compressing those 4 bits into bit
31, as a result we just have to perform a check against the value being
negative to determine if we are looking at a debug level (positive), or a
debug mask (negative). The debug level will populate the msg_level, and
the debug mask will populate the debug_mask in the hardware struct.
I added similar logic for ethtool. If the value being provided has bit 31
set we assume the value being provided is a debug mask, otherwise we assume
it is a msg_enable mask. For displaying we only provide the msg_enable,
and if debug_mask is in use we will print it to the dmesg log.
Lastly I removed the debugfs interface. It is redundant with what we
already have in ethtool and really doesn't belong anyway.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 19 -------------------
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 7 ++++++-
drivers/net/ethernet/intel/i40e/i40e_main.c | 23 ++++++++---------------
3 files changed, 14 insertions(+), 35 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
index 0c1875b..0354632 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
@@ -1210,24 +1210,6 @@ static ssize_t i40e_dbg_command_write(struct file *filp,
dev_info(&pf->pdev->dev,
"dump debug fwdata <cluster_id> <table_id> <index>\n");
}
-
- } else if (strncmp(cmd_buf, "msg_enable", 10) == 0) {
- u32 level;
- cnt = sscanf(&cmd_buf[10], "%i", &level);
- if (cnt) {
- if (I40E_DEBUG_USER & level) {
- pf->hw.debug_mask = level;
- dev_info(&pf->pdev->dev,
- "set hw.debug_mask = 0x%08x\n",
- pf->hw.debug_mask);
- }
- pf->msg_enable = level;
- dev_info(&pf->pdev->dev, "set msg_enable = 0x%08x\n",
- pf->msg_enable);
- } else {
- dev_info(&pf->pdev->dev, "msg_enable = 0x%08x\n",
- pf->msg_enable);
- }
} else if (strncmp(cmd_buf, "pfr", 3) == 0) {
dev_info(&pf->pdev->dev, "debugfs: forcing PFR\n");
i40e_do_reset_safe(pf, BIT(__I40E_PF_RESET_REQUESTED));
@@ -1644,7 +1626,6 @@ static ssize_t i40e_dbg_command_write(struct file *filp,
dev_info(&pf->pdev->dev, " dump desc aq\n");
dev_info(&pf->pdev->dev, " dump reset stats\n");
dev_info(&pf->pdev->dev, " dump debug fwdata <cluster_id> <table_id> <index>\n");
- dev_info(&pf->pdev->dev, " msg_enable [level]\n");
dev_info(&pf->pdev->dev, " read <reg>\n");
dev_info(&pf->pdev->dev, " write <reg> <value>\n");
dev_info(&pf->pdev->dev, " clear_stats vsi [seid]\n");
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 3a1f91e..fb4fb52 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -978,6 +978,10 @@ static u32 i40e_get_msglevel(struct net_device *netdev)
{
struct i40e_netdev_priv *np = netdev_priv(netdev);
struct i40e_pf *pf = np->vsi->back;
+ u32 debug_mask = pf->hw.debug_mask;
+
+ if (debug_mask)
+ netdev_info(netdev, "i40e debug_mask: 0x%08X\n", debug_mask);
return pf->msg_enable;
}
@@ -989,7 +993,8 @@ static void i40e_set_msglevel(struct net_device *netdev, u32 data)
if (I40E_DEBUG_USER & data)
pf->hw.debug_mask = data;
- pf->msg_enable = data;
+ else
+ pf->msg_enable = data;
}
static int i40e_get_regs_len(struct net_device *netdev)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 0c2328d..7fa535f 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -93,8 +93,8 @@ MODULE_DEVICE_TABLE(pci, i40e_pci_tbl);
#define I40E_MAX_VF_COUNT 128
static int debug = -1;
-module_param(debug, int, 0);
-MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
+module_param(debug, uint, 0);
+MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all), Debug mask (0x8XXXXXXX)");
MODULE_AUTHOR("Intel Corporation, <e1000-devel@lists.sourceforge.net>");
MODULE_DESCRIPTION("Intel(R) Ethernet Connection XL710 Network Driver");
@@ -8511,15 +8511,6 @@ static int i40e_sw_init(struct i40e_pf *pf)
int err = 0;
int size;
- pf->msg_enable = netif_msg_init(I40E_DEFAULT_MSG_ENABLE,
- (NETIF_MSG_DRV|NETIF_MSG_PROBE|NETIF_MSG_LINK));
- if (debug != -1 && debug != I40E_DEFAULT_MSG_ENABLE) {
- if (I40E_DEBUG_USER & debug)
- pf->hw.debug_mask = debug;
- pf->msg_enable = netif_msg_init((debug & ~I40E_DEBUG_USER),
- I40E_DEFAULT_MSG_ENABLE);
- }
-
/* Set default capability flags */
pf->flags = I40E_FLAG_RX_CSUM_ENABLED |
I40E_FLAG_MSI_ENABLED |
@@ -10825,10 +10816,12 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
mutex_init(&hw->aq.asq_mutex);
mutex_init(&hw->aq.arq_mutex);
- if (debug != -1) {
- pf->msg_enable = pf->hw.debug_mask;
- pf->msg_enable = debug;
- }
+ pf->msg_enable = netif_msg_init(debug,
+ NETIF_MSG_DRV |
+ NETIF_MSG_PROBE |
+ NETIF_MSG_LINK);
+ if (debug < -1)
+ pf->hw.debug_mask = debug;
/* do a special CORER for clearing PXE mode once at init */
if (hw->revision_id == 0 &&
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] add one parameter wro_enable to enable relaxed ordering for IXGBE
From: Jeff Kirsher @ 2016-10-29 7:42 UTC (permalink / raw)
To: Mao Wenan, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <1477724932-5440-1-git-send-email-maowenan@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]
On Sat, 2016-10-29 at 15:08 +0800, Mao Wenan wrote:
> This patch provides a way to enable relaxed ordering, where it helps with
> performance in some architecture.
> The default value of wro_enable is 0, if you want to enable relaxed
> ordering, please set wro_enable=1.
>
> Mao Wenan (1):
> add one parameter wro_enable for IXGBE
>
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 29 ++++++++++++++-----
> ------
> drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 28 +++++++++++++----
> -------
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 ++++++++
> 4 files changed, 41 insertions(+), 26 deletions(-)
Why have a title patch for only one patch? Better yet, the one patch does
not have a patch description. Get rid of the title patch and add the above
information into the patches description.
In addition, module parameters are not kindly looked upon, one reason is
that it cannot be standardized and enforced.
I am also confused because you are stating that on some architectures, yet
this code is only compiled in when SPARC is defined and that there are
times when you want relaxed ordering enabled and other times disabled?
Your gonna have to provide more data on why, because the code as is was
resolving serious performance issues on SPARC when relaxed ordering was
enabled.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Let's do P4
From: Jiri Pirko @ 2016-10-29 7:53 UTC (permalink / raw)
To: netdev
Cc: davem, tgraf, jhs, roopa, john.fastabend, jakub.kicinski,
simon.horman, ast, daniel, prem, hannes, jbenc, tom, mattyk,
idosch, eladr, yotamg, nogahf, ogerlitz, linville, andy,
f.fainelli, dsa, vivien.didelot, andrew, ivecera
Hi all.
The network world is divided into 2 general types of hw:
1) network ASICs - network specific silicon, containing things like TCAM
These ASICs are suitable to be programmed by P4.
2) network processors - basically a general purpose CPUs
These processors are suitable to be programmed by eBPF.
I believe that by now, the most people came to a conclusion that it is
very difficult to handle both types by either P4 or eBPF. And since
eBPF is part of the kernel, I would like to introduce P4 into kernel
as well. Here's a plan:
1) Define P4 intermediate representation
I cannot imagine loading P4 program (c-like syntax text file) into
kernel as is. That means that as the first step, we need find some
intermediate representation. I can imagine someting in a form of AST,
call it "p4ast". I don't really know how to do this exactly though,
it's just an idea.
In the end there would be a userspace precompiler for this:
$ makep4ast example.p4 example.ast
2) Implement p4ast in-kernel interpreter
A kernel module which takes a p4ast and emulates the pipeline.
This can be implemented from scratch. Or, p4ast could be compiled
to eBPF. I know there are already couple of p4>eBPF compilers.
Not sure how feasible it would be to put this compiler in kernel.
3) Expose the p4ast in-kernel interpreter to userspace
As the easiest way I see in to introduce a new TC classifier cls_p4.
This can work in a very similar way cls_bpf is:
$ tc filter add dev eth0 ingress p4 da ast example.ast
The TC cls_p4 will be also used for runtime table manipulation.
4) Offload p4ast programs into hardware
The same p4ast program representation will be passed down
to drivers via existing TC offloading way - ndo_setup_tc.
Drivers will then parse it and setup the hardware
accordingly. Driver will also have possibility to error out
in case it does not support some requested feature.
Thoughts? Ideas?
Thanks,
Jiri
^ permalink raw reply
* Re: [PATCH net-next] udp: do fwd memory scheduling on dequeue
From: Paolo Abeni @ 2016-10-29 8:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller, James Morris,
Trond Myklebust, Alexander Duyck, Daniel Borkmann, Eric Dumazet,
Tom Herbert, Hannes Frederic Sowa,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477677030.7065.250.camel-XN9IlZ5yJG9HTL0Zs8A6p+yfmBU6pStAUsxypvmhUTTZJqsBc5GL+g@public.gmane.org>
On Fri, 2016-10-28 at 10:50 -0700, Eric Dumazet wrote:
> On Fri, 2016-10-28 at 10:16 -0700, Eric Dumazet wrote:
> > Nice !
> >
> > I was working on this as well and my implementation was somewhat
> > different.
>
> This is my WIP
>
> Note this can be split in two parts.
>
> 1) One adding struct sock *sk param to ip_cmsg_recv_offset()
>
> This was because I left skb->sk NULL for skbs stored in receive
> queue.
> You chose instead to set skb->sk, which is unusual (check
> skb_orphan() BUG_ON())
>
> 2) Udp changes.
>
> Tell me what you think, thanks again !
Thank you for working on this.
I just gave a very quick look (the WE has started, children are
screaming ;-), overall the implementation seems quite similar to our
one.
I like the additional argument to ip_cmsg_recv_offset() instead of
keeping skb->sk set.
If I read udp_skb_destructor() correctly, the atomic manipulation of
both sk_rmem_alloc and udp_memory_allocated will happen under the
receive lock. In our experiments this increment measurably the
contention on the lock in respect to moving said the operations outside
the lock (as done in our patch). Do you foreseen any issues with that ?
AFAICS every in kernel UDP user of skb_recv_datagram() needs to be
updated with both implementation.
Cheers,
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Andrew Lunn @ 2016-10-29 8:18 UTC (permalink / raw)
To: Jon Mason
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli,
devicetree, netdev, linux-kernel, bcm-kernel-feedback-list, rafal,
linux-arm-kernel
In-Reply-To: <1477688219-3871-3-git-send-email-jon.mason@broadcom.com>
On Fri, Oct 28, 2016 at 04:56:55PM -0400, Jon Mason wrote:
> The BCM54810 PHY requires some semi-unique configuration, which results
> in some additional configuration in addition to the standard config.
> Also, some users of the BCM54810 require the PHY lanes to be swapped.
> Since there is no way to detect this, add a device tree query to see if
> it is applicable.
>
> Inspired-by: Vikas Soni <vsoni@broadcom.com>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> drivers/net/phy/Kconfig | 2 +-
> drivers/net/phy/broadcom.c | 58 +++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/brcmphy.h | 10 ++++++++
Hi Jon
The binding documentation is missing.
> + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap")) {
> + /* Lane Swap - Undocumented register...magic! */
> + ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
> + 0x11B);
> + if (ret < 0)
> + return ret;
> + }
> +
I wounder if this property could be made generic? What exactly are you
swapping? Rx and Tx lanes? Maybe we should add it to phy.txt?
Andrew
^ permalink raw reply
* Re: Let's do P4
From: Thomas Graf @ 2016-10-29 9:39 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, roopa, john.fastabend, jakub.kicinski,
simon.horman, ast, daniel, prem, hannes, jbenc, tom, mattyk,
idosch, eladr, yotamg, nogahf, ogerlitz, linville, andy,
f.fainelli, dsa, vivien.didelot, andrew, ivecera
In-Reply-To: <20161029075328.GB1692@nanopsycho.orion>
On 10/29/16 at 09:53am, Jiri Pirko wrote:
> Hi all.
>
> The network world is divided into 2 general types of hw:
> 1) network ASICs - network specific silicon, containing things like TCAM
> These ASICs are suitable to be programmed by P4.
> 2) network processors - basically a general purpose CPUs
> These processors are suitable to be programmed by eBPF.
>
> I believe that by now, the most people came to a conclusion that it is
> very difficult to handle both types by either P4 or eBPF. And since
> eBPF is part of the kernel, I would like to introduce P4 into kernel
> as well. Here's a plan:
For reference, last time I remember we discussed this in the BPF
offload context:
http://www.spinics.net/lists/netdev/msg356178.html
> 1) Define P4 intermediate representation
> I cannot imagine loading P4 program (c-like syntax text file) into
> kernel as is. That means that as the first step, we need find some
> intermediate representation. I can imagine someting in a form of AST,
> call it "p4ast". I don't really know how to do this exactly though,
> it's just an idea.
>
> In the end there would be a userspace precompiler for this:
> $ makep4ast example.p4 example.ast
>
> 2) Implement p4ast in-kernel interpreter
> A kernel module which takes a p4ast and emulates the pipeline.
> This can be implemented from scratch. Or, p4ast could be compiled
> to eBPF. I know there are already couple of p4>eBPF compilers.
> Not sure how feasible it would be to put this compiler in kernel.
+1 to using eBPF for emulation. Maybe the compiler doesn't need to be
in the kernel and user space can compile and provide the emulated
pipeline in eBPF directly. See next paragraph for an example where
this could be useful.
> 3) Expose the p4ast in-kernel interpreter to userspace
> As the easiest way I see in to introduce a new TC classifier cls_p4.
>
> This can work in a very similar way cls_bpf is:
> $ tc filter add dev eth0 ingress p4 da ast example.ast
>
> The TC cls_p4 will be also used for runtime table manipulation.
I think this is a great model for the case where HW can provide all
of the required capabilities. Thinking about the case where HW
provides a subset and SW provides an extended version, i.e. the
reality we live in for hosts with ASIC NICs ;-) The hand off point
requires some understanding between p4ast and eBPF.
Therefore another idea would be to use cls_bpf directly for this. The
p4ast IR could be stored in a separate ELF section in the same object
file with an existing eBPF program. The p4ast IR will match the
eBPF prog if capabilities of HW and SW match. If HW is limited, the
p4ast IR represents what the HW can do plus how to pass it to SW. The
eBPF prog contains whatever logic is required to take over if the HW
either bailed out or handed over deliberately. Then on top, all the
missing pieces of functionality which can only be performed in SW.
tc then loads 1) eBPF maps and prog through bpf() syscall
2) cls_bpf filter with p4ast IR plus ref to prog and
maps
> 4) Offload p4ast programs into hardware
> The same p4ast program representation will be passed down
> to drivers via existing TC offloading way - ndo_setup_tc.
> Drivers will then parse it and setup the hardware
> accordingly. Driver will also have possibility to error out
> in case it does not support some requested feature.
^ permalink raw reply
* Re: Let's do P4
From: Jiri Pirko @ 2016-10-29 10:10 UTC (permalink / raw)
To: Thomas Graf
Cc: netdev, davem, jhs, roopa, john.fastabend, jakub.kicinski,
simon.horman, ast, daniel, prem, hannes, jbenc, tom, mattyk,
idosch, eladr, yotamg, nogahf, ogerlitz, linville, andy,
f.fainelli, dsa, vivien.didelot, andrew, ivecera
In-Reply-To: <20161029093905.GA1810@pox.localdomain>
Sat, Oct 29, 2016 at 11:39:05AM CEST, tgraf@suug.ch wrote:
>On 10/29/16 at 09:53am, Jiri Pirko wrote:
>> Hi all.
>>
>> The network world is divided into 2 general types of hw:
>> 1) network ASICs - network specific silicon, containing things like TCAM
>> These ASICs are suitable to be programmed by P4.
>> 2) network processors - basically a general purpose CPUs
>> These processors are suitable to be programmed by eBPF.
>>
>> I believe that by now, the most people came to a conclusion that it is
>> very difficult to handle both types by either P4 or eBPF. And since
>> eBPF is part of the kernel, I would like to introduce P4 into kernel
>> as well. Here's a plan:
>
>For reference, last time I remember we discussed this in the BPF
>offload context:
>http://www.spinics.net/lists/netdev/msg356178.html
>
>> 1) Define P4 intermediate representation
>> I cannot imagine loading P4 program (c-like syntax text file) into
>> kernel as is. That means that as the first step, we need find some
>> intermediate representation. I can imagine someting in a form of AST,
>> call it "p4ast". I don't really know how to do this exactly though,
>> it's just an idea.
>>
>> In the end there would be a userspace precompiler for this:
>> $ makep4ast example.p4 example.ast
>>
>> 2) Implement p4ast in-kernel interpreter
>> A kernel module which takes a p4ast and emulates the pipeline.
>> This can be implemented from scratch. Or, p4ast could be compiled
>> to eBPF. I know there are already couple of p4>eBPF compilers.
>> Not sure how feasible it would be to put this compiler in kernel.
>
>+1 to using eBPF for emulation. Maybe the compiler doesn't need to be
>in the kernel and user space can compile and provide the emulated
>pipeline in eBPF directly. See next paragraph for an example where
>this could be useful.
Ditto.
>
>> 3) Expose the p4ast in-kernel interpreter to userspace
>> As the easiest way I see in to introduce a new TC classifier cls_p4.
>>
>> This can work in a very similar way cls_bpf is:
>> $ tc filter add dev eth0 ingress p4 da ast example.ast
>>
>> The TC cls_p4 will be also used for runtime table manipulation.
>
>I think this is a great model for the case where HW can provide all
>of the required capabilities. Thinking about the case where HW
>provides a subset and SW provides an extended version, i.e. the
>reality we live in for hosts with ASIC NICs ;-) The hand off point
>requires some understanding between p4ast and eBPF.
It can be the other way around. The p4>ebpf compiler won't be complete
at the beginning so it is possible that HW could provide more features.
I don't think it is a problem. With SKIP_SW and SKIP_HW flags in TC,
the user can set different program to each. I think in real life, that
would be the most common case anyway.
>
>Therefore another idea would be to use cls_bpf directly for this. The
>p4ast IR could be stored in a separate ELF section in the same object
>file with an existing eBPF program. The p4ast IR will match the
I don't like this idea. The kernel API should be clean and simple.
Bundling p4ast with bpf.o code, so the bpf.o is for kernel and p4ast is
for driver does not look clean at all. The bundle does not make really
sense as the programs may do different things for BPF and p4.
Plus, it's up to user to set this up like he wants. If he wants SW
processing by BPF and at the same time HW processing by P4, he will use:
cls_bpf instance with SKIP_HW
cls_p4 instance with SKIP_SW.
This is much more variable, clean and non-confusing approach, I believe.
>eBPF prog if capabilities of HW and SW match. If HW is limited, the
>p4ast IR represents what the HW can do plus how to pass it to SW. The
>eBPF prog contains whatever logic is required to take over if the HW
>either bailed out or handed over deliberately. Then on top, all the
>missing pieces of functionality which can only be performed in SW.
>
>tc then loads 1) eBPF maps and prog through bpf() syscall
> 2) cls_bpf filter with p4ast IR plus ref to prog and
> maps
>
>> 4) Offload p4ast programs into hardware
>> The same p4ast program representation will be passed down
>> to drivers via existing TC offloading way - ndo_setup_tc.
>> Drivers will then parse it and setup the hardware
>> accordingly. Driver will also have possibility to error out
>> in case it does not support some requested feature.
^ permalink raw reply
* Re: [PATCH 03/17] batman-adv: Add network_coding and mcast sysfs files to README
From: Jiri Pirko @ 2016-10-29 10:33 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: davem, netdev, b.a.t.m.a.n, Sven Eckelmann
In-Reply-To: <20161027190150.7880-4-sw@simonwunderlich.de>
Thu, Oct 27, 2016 at 09:01:36PM CEST, sw@simonwunderlich.de wrote:
>From: Sven Eckelmann <sven@narfation.org>
>
>Signed-off-by: Sven Eckelmann <sven@narfation.org>
>Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
>---
> Documentation/networking/batman-adv.txt | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
>diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt
>index d414e60..8afa991 100644
>--- a/Documentation/networking/batman-adv.txt
>+++ b/Documentation/networking/batman-adv.txt
>@@ -71,10 +71,11 @@ All mesh wide settings can be found in batman's own interface
> folder:
>
> # ls /sys/class/net/bat0/mesh/
>-#aggregated_ogms distributed_arp_table gw_sel_class orig_interval
>-#ap_isolation fragmentation hop_penalty routing_algo
>-#bonding gw_bandwidth isolation_mark vlan0
>-#bridge_loop_avoidance gw_mode log_level
>+# aggregated_ogms fragmentation isolation_mark routing_algo
>+# ap_isolation gw_bandwidth log_level vlan0
>+# bonding gw_mode multicast_mode
>+# bridge_loop_avoidance gw_sel_class network_coding
>+# distributed_arp_table hop_penalty orig_interval
I strongly believe it is a huge mistake to use sysfs for things like
this. This should be done via generic netlink api.
>
^ permalink raw reply
* Re: [PATCH 03/17] batman-adv: Add network_coding and mcast sysfs files to README
From: Sven Eckelmann @ 2016-10-29 10:37 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Simon Wunderlich, davem, netdev, b.a.t.m.a.n
In-Reply-To: <20161029103301.GD1692@nanopsycho.orion>
[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]
On Samstag, 29. Oktober 2016 12:33:01 CEST Jiri Pirko wrote:
[...]
> >--- a/Documentation/networking/batman-adv.txt
> >+++ b/Documentation/networking/batman-adv.txt
> >@@ -71,10 +71,11 @@ All mesh wide settings can be found in batman's own interface
> > folder:
> >
> > # ls /sys/class/net/bat0/mesh/
> >-#aggregated_ogms distributed_arp_table gw_sel_class orig_interval
> >-#ap_isolation fragmentation hop_penalty routing_algo
> >-#bonding gw_bandwidth isolation_mark vlan0
> >-#bridge_loop_avoidance gw_mode log_level
> >+# aggregated_ogms fragmentation isolation_mark routing_algo
> >+# ap_isolation gw_bandwidth log_level vlan0
> >+# bonding gw_mode multicast_mode
> >+# bridge_loop_avoidance gw_sel_class network_coding
> >+# distributed_arp_table hop_penalty orig_interval
>
> I strongly believe it is a huge mistake to use sysfs for things like
> this. This should be done via generic netlink api.
This doesn't change the problem that it is already that way. This patch
only adds the list of available files to the README.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 03/17] batman-adv: Add network_coding and mcast sysfs files to README
From: Jiri Pirko @ 2016-10-29 10:56 UTC (permalink / raw)
To: Sven Eckelmann
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <22392280.4UY6GoIrAk@sven-edge>
Sat, Oct 29, 2016 at 12:37:07PM CEST, sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org wrote:
>On Samstag, 29. Oktober 2016 12:33:01 CEST Jiri Pirko wrote:
>[...]
>> >--- a/Documentation/networking/batman-adv.txt
>> >+++ b/Documentation/networking/batman-adv.txt
>> >@@ -71,10 +71,11 @@ All mesh wide settings can be found in batman's own interface
>> > folder:
>> >
>> > # ls /sys/class/net/bat0/mesh/
>> >-#aggregated_ogms distributed_arp_table gw_sel_class orig_interval
>> >-#ap_isolation fragmentation hop_penalty routing_algo
>> >-#bonding gw_bandwidth isolation_mark vlan0
>> >-#bridge_loop_avoidance gw_mode log_level
>> >+# aggregated_ogms fragmentation isolation_mark routing_algo
>> >+# ap_isolation gw_bandwidth log_level vlan0
>> >+# bonding gw_mode multicast_mode
>> >+# bridge_loop_avoidance gw_sel_class network_coding
>> >+# distributed_arp_table hop_penalty orig_interval
>>
>> I strongly believe it is a huge mistake to use sysfs for things like
>> this. This should be done via generic netlink api.
>
>This doesn't change the problem that it is already that way. This patch
>only adds the list of available files to the README.
Sure. Just found out you did it like that. Therefore I commented. I
suggest to rework the api to use genl entirely.
>
>Kind regards,
> Sven
^ permalink raw reply
* Re: Let's do P4
From: Thomas Graf @ 2016-10-29 11:15 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, roopa, john.fastabend, jakub.kicinski,
simon.horman, ast, daniel, prem, hannes, jbenc, tom, mattyk,
idosch, eladr, yotamg, nogahf, ogerlitz, linville, andy,
f.fainelli, dsa, vivien.didelot, andrew, ivecera
In-Reply-To: <20161029101003.GC1692@nanopsycho.orion>
On 10/29/16 at 12:10pm, Jiri Pirko wrote:
> Sat, Oct 29, 2016 at 11:39:05AM CEST, tgraf@suug.ch wrote:
> >On 10/29/16 at 09:53am, Jiri Pirko wrote:
> >> 3) Expose the p4ast in-kernel interpreter to userspace
> >> As the easiest way I see in to introduce a new TC classifier cls_p4.
> >>
> >> This can work in a very similar way cls_bpf is:
> >> $ tc filter add dev eth0 ingress p4 da ast example.ast
> >>
> >> The TC cls_p4 will be also used for runtime table manipulation.
> >
> >I think this is a great model for the case where HW can provide all
> >of the required capabilities. Thinking about the case where HW
> >provides a subset and SW provides an extended version, i.e. the
> >reality we live in for hosts with ASIC NICs ;-) The hand off point
> >requires some understanding between p4ast and eBPF.
>
> It can be the other way around. The p4>ebpf compiler won't be complete
> at the beginning so it is possible that HW could provide more features.
> I don't think it is a problem. With SKIP_SW and SKIP_HW flags in TC,
> the user can set different program to each. I think in real life, that
> would be the most common case anyway.
So given the SKIP_SW flag, the in-kernel compiler is optional anyway.
Why even risk including a possibly incomplete compiler? Older kernels
must be capable of running along newer hardware as long as eBPF can
represent the software path. Having to upgrade to latest and greatest
kernels is not an option for most people so they would simply have to
fall back to SKIP_SW and do it in user space anyway.
> >Therefore another idea would be to use cls_bpf directly for this. The
> >p4ast IR could be stored in a separate ELF section in the same object
> >file with an existing eBPF program. The p4ast IR will match the
>
> I don't like this idea. The kernel API should be clean and simple.
> Bundling p4ast with bpf.o code, so the bpf.o is for kernel and p4ast is
> for driver does not look clean at all. The bundle does not make really
> sense as the programs may do different things for BPF and p4.
I don't care strongly for the bundle. Let's forget about it for now.
> Plus, it's up to user to set this up like he wants. If he wants SW
> processing by BPF and at the same time HW processing by P4, he will use:
> cls_bpf instance with SKIP_HW
> cls_p4 instance with SKIP_SW.
>
> This is much more variable, clean and non-confusing approach, I believe.
Non ASIC hardware will want to do offload based on BPF though so your
model would require the user to be aware of what is the preferred
model for his hardware and then either load a cls_bpf only to work
with a Netronome NIC or a cls_p4 + cls_bpf to work with an ASIC NIC,
correct?
I'm not seeing how either of them is more or less variable. The main
difference is whether to require configuring a single cls with both
p4ast + bpf or two separate cls, one for each. I'd prefer the single
cls approach simply because it is cleaner wither regard to offload
directly off bpf vs off p4ast.
My main point is to not include a IR to eBPF compiler in the kernel
and let user space handle this instead.
^ permalink raw reply
* [PATCH 1/1] ath10k: use the right length of "background"
From: Nicolas Iooss @ 2016-10-29 11:17 UTC (permalink / raw)
To: Kalle Valo, ath10k; +Cc: netdev, linux-wireless, linux-kernel, Nicolas Iooss
The word "background" contains 10 characters so the third argument of
strncmp() need to be 10 in order to match this prefix correctly.
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Fixes: 855aed1220d2 ("ath10k: add spectral scan feature")
---
drivers/net/wireless/ath/ath10k/spectral.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/spectral.c b/drivers/net/wireless/ath/ath10k/spectral.c
index 7d9b0da1b010..2ffc1fe4923b 100644
--- a/drivers/net/wireless/ath/ath10k/spectral.c
+++ b/drivers/net/wireless/ath/ath10k/spectral.c
@@ -338,7 +338,7 @@ static ssize_t write_file_spec_scan_ctl(struct file *file,
} else {
res = -EINVAL;
}
- } else if (strncmp("background", buf, 9) == 0) {
+ } else if (strncmp("background", buf, 10) == 0) {
res = ath10k_spectral_scan_config(ar, SPECTRAL_BACKGROUND);
} else if (strncmp("manual", buf, 6) == 0) {
res = ath10k_spectral_scan_config(ar, SPECTRAL_MANUAL);
--
2.10.1
^ permalink raw reply related
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: Thomas Graf @ 2016-10-29 11:25 UTC (permalink / raw)
To: Shrijeet Mukherjee
Cc: Alexei Starovoitov, Jakub Kicinski, John Fastabend, David Miller,
alexander.duyck, mst, brouer, shrijeet, tom, netdev, Roopa Prabhu,
Nikolay Aleksandrov
In-Reply-To: <ec23c734c23d81884349484927140741@mail.gmail.com>
On 10/28/16 at 08:51pm, Shrijeet Mukherjee wrote:
> Generally agree, but SRIOV nics with multiple queues can end up in a bad
> spot if each buffer was 4K right ? I see a specific page pool to be used
> by queues which are enabled for XDP as the easiest to swing solution that
> way the memory overhead can be restricted to enabled queues and shared
> access issues can be restricted to skb's using that pool no ?
Isn't this clearly a must anyway? I may be missing something
fundamental here so please enlighten me :-)
If we dedicate a page per packet, that could translate to 14M*4K worth
of memory being mapped per second for just a 10G NIC under DoS attack.
How can one protect such as system? Is the assumption that we can always
drop such packets quickly enough before we start dropping randomly due
to memory pressure? If a handshake is required to determine validity
of a packet then that is going to be difficult.
^ permalink raw reply
* Re: Let's do P4
From: Jiri Pirko @ 2016-10-29 11:28 UTC (permalink / raw)
To: Thomas Graf
Cc: netdev, davem, jhs, roopa, john.fastabend, jakub.kicinski,
simon.horman, ast, daniel, prem, hannes, jbenc, tom, mattyk,
idosch, eladr, yotamg, nogahf, ogerlitz, linville, andy,
f.fainelli, dsa, vivien.didelot, andrew, ivecera
In-Reply-To: <20161029111548.GB1810@pox.localdomain>
Sat, Oct 29, 2016 at 01:15:48PM CEST, tgraf@suug.ch wrote:
>On 10/29/16 at 12:10pm, Jiri Pirko wrote:
>> Sat, Oct 29, 2016 at 11:39:05AM CEST, tgraf@suug.ch wrote:
>> >On 10/29/16 at 09:53am, Jiri Pirko wrote:
>> >> 3) Expose the p4ast in-kernel interpreter to userspace
>> >> As the easiest way I see in to introduce a new TC classifier cls_p4.
>> >>
>> >> This can work in a very similar way cls_bpf is:
>> >> $ tc filter add dev eth0 ingress p4 da ast example.ast
>> >>
>> >> The TC cls_p4 will be also used for runtime table manipulation.
>> >
>> >I think this is a great model for the case where HW can provide all
>> >of the required capabilities. Thinking about the case where HW
>> >provides a subset and SW provides an extended version, i.e. the
>> >reality we live in for hosts with ASIC NICs ;-) The hand off point
>> >requires some understanding between p4ast and eBPF.
>>
>> It can be the other way around. The p4>ebpf compiler won't be complete
>> at the beginning so it is possible that HW could provide more features.
>> I don't think it is a problem. With SKIP_SW and SKIP_HW flags in TC,
>> the user can set different program to each. I think in real life, that
>> would be the most common case anyway.
>
>So given the SKIP_SW flag, the in-kernel compiler is optional anyway.
>Why even risk including a possibly incomplete compiler? Older kernels
>must be capable of running along newer hardware as long as eBPF can
>represent the software path. Having to upgrade to latest and greatest
>kernels is not an option for most people so they would simply have to
>fall back to SKIP_SW and do it in user space anyway.
The thing is, if we needo to offload something, it needs to be
implemented in kernel first. Also, I believe that it is good to have
in-kernel p4 engine for testing and development purposes.
>
>> >Therefore another idea would be to use cls_bpf directly for this. The
>> >p4ast IR could be stored in a separate ELF section in the same object
>> >file with an existing eBPF program. The p4ast IR will match the
>>
>> I don't like this idea. The kernel API should be clean and simple.
>> Bundling p4ast with bpf.o code, so the bpf.o is for kernel and p4ast is
>> for driver does not look clean at all. The bundle does not make really
>> sense as the programs may do different things for BPF and p4.
>
>I don't care strongly for the bundle. Let's forget about it for now.
>
>> Plus, it's up to user to set this up like he wants. If he wants SW
>> processing by BPF and at the same time HW processing by P4, he will use:
>> cls_bpf instance with SKIP_HW
>> cls_p4 instance with SKIP_SW.
>>
>> This is much more variable, clean and non-confusing approach, I believe.
>
>Non ASIC hardware will want to do offload based on BPF though so your
>model would require the user to be aware of what is the preferred
>model for his hardware and then either load a cls_bpf only to work
>with a Netronome NIC or a cls_p4 + cls_bpf to work with an ASIC NIC,
>correct?
Correct
>
>I'm not seeing how either of them is more or less variable. The main
>difference is whether to require configuring a single cls with both
>p4ast + bpf or two separate cls, one for each. I'd prefer the single
>cls approach simply because it is cleaner wither regard to offload
>directly off bpf vs off p4ast.
That's the bundle that you asked me to forget earlier in this email? :)
>
>My main point is to not include a IR to eBPF compiler in the kernel
>and let user space handle this instead.
It we do it as you describe, we would be using 2 different APIs for
offloaded and non-offloaded path. I don't believe it is acceptable as
the offloaded features has to have kernel implementation. Therefore, I
believe that p4ast as a kernel API is the only possible option.
^ permalink raw reply
* Re: [PATCH 03/17] batman-adv: Add network_coding and mcast sysfs files to README
From: Sven Eckelmann @ 2016-10-29 11:46 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20161029105628.GE1692-6KJVSR23iU488b5SBfVpbw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 783 bytes --]
On Samstag, 29. Oktober 2016 12:56:28 CEST Jiri Pirko wrote:
[...]
> >> I strongly believe it is a huge mistake to use sysfs for things like
> >> this. This should be done via generic netlink api.
> >
> >This doesn't change the problem that it is already that way. This patch
> >only adds the list of available files to the README.
>
> Sure. Just found out you did it like that. Therefore I commented. I
> suggest to rework the api to use genl entirely.
Fair enough, I have added it to the issue tracker [1].
It seems there is no easy way to drop support for modifying batman-adv
attributes of the interface or its ports via sysfs in the near
future. But disallowing sysfs for new attributes might be a viable
policy.
Kind regards,
Sven
[1] https://www.open-mesh.org/issues/300
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Let's do P4
From: Thomas Graf @ 2016-10-29 12:09 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, roopa, john.fastabend, jakub.kicinski,
simon.horman, ast, daniel, prem, hannes, jbenc, tom, mattyk,
idosch, eladr, yotamg, nogahf, ogerlitz, linville, andy,
f.fainelli, dsa, vivien.didelot, andrew, ivecera
In-Reply-To: <20161029112834.GF1692@nanopsycho.orion>
On 10/29/16 at 01:28pm, Jiri Pirko wrote:
> Sat, Oct 29, 2016 at 01:15:48PM CEST, tgraf@suug.ch wrote:
> >So given the SKIP_SW flag, the in-kernel compiler is optional anyway.
> >Why even risk including a possibly incomplete compiler? Older kernels
> >must be capable of running along newer hardware as long as eBPF can
> >represent the software path. Having to upgrade to latest and greatest
> >kernels is not an option for most people so they would simply have to
> >fall back to SKIP_SW and do it in user space anyway.
>
> The thing is, if we needo to offload something, it needs to be
> implemented in kernel first. Also, I believe that it is good to have
> in-kernel p4 engine for testing and development purposes.
You lost me now :-) In an earlier email you said:
> It can be the other way around. The p4>ebpf compiler won't be complete
> at the beginning so it is possible that HW could provide more features.
> I don't think it is a problem. With SKIP_SW and SKIP_HW flags in TC,
> the user can set different program to each. I think in real life, that
> would be the most common case anyway.
If you allow to SKIP_SW and set different programs each to address
this, then how is this any different.
I completely agree that kernel must be able to provide the same
functionality as HW with optional additional capabilities on top so
the HW can always bail out and punt to SW.
[...]
> >I'm not seeing how either of them is more or less variable. The main
> >difference is whether to require configuring a single cls with both
> >p4ast + bpf or two separate cls, one for each. I'd prefer the single
> >cls approach simply because it is cleaner wither regard to offload
> >directly off bpf vs off p4ast.
>
> That's the bundle that you asked me to forget earlier in this email? :)
I thought you referred to the "store in same object file" as bundle.
I don't really care about that. What I care about is a single way to
configure this that works for both ASIC and non-ASIC hardware.
> >My main point is to not include a IR to eBPF compiler in the kernel
> >and let user space handle this instead.
>
> It we do it as you describe, we would be using 2 different APIs for
> offloaded and non-offloaded path. I don't believe it is acceptable as
> the offloaded features has to have kernel implementation. Therefore, I
> believe that p4ast as a kernel API is the only possible option.
Yes, the kernel has the SW implementation in eBPF. I thought that is
what you propose as well. The only difference is whether to generate
that eBPF in kernel or user space.
Not sure I understand the multiple APIs point for offload vs
non-offload. There is a single API: tc. Both models require the user
to provide additional metadata to allow programming ASIC HW: p4ast
IR or whatever we agree on.
^ permalink raw reply
* Re: [PATCH net-next] udp: do fwd memory scheduling on dequeue
From: Eric Dumazet @ 2016-10-29 12:43 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller, James Morris,
Trond Myklebust, Alexander Duyck, Daniel Borkmann, Eric Dumazet,
Tom Herbert, Hannes Frederic Sowa,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477729045.5306.11.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Sat, 2016-10-29 at 10:17 +0200, Paolo Abeni wrote:
> Thank you for working on this.
>
> I just gave a very quick look (the WE has started, children are
> screaming ;-), overall the implementation seems quite similar to our
> one.
>
> I like the additional argument to ip_cmsg_recv_offset() instead of
> keeping skb->sk set.
>
> If I read udp_skb_destructor() correctly, the atomic manipulation of
> both sk_rmem_alloc and udp_memory_allocated will happen under the
> receive lock. In our experiments this increment measurably the
> contention on the lock in respect to moving said the operations outside
> the lock (as done in our patch). Do you foreseen any issues with that ?
> AFAICS every in kernel UDP user of skb_recv_datagram() needs to be
> updated with both implementation.
So if you look at tcp, we do not release forward allocation at every
recvmsg(), but rather when we are under tcp memory pressure, or at timer
firing when we know the flow has been idle for a while.
You hit contention on the lock, but the root cause is that right now udp
is very conservative and also hits false sharing on
udp_memory_allocated.
So I believe this is another problem which needs a fix anyway.
No need to make a complicated patch right now, if we know that this
problem will be separately fixed, in another patch ?
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: net-next still on 4.8.0?
From: David Miller @ 2016-10-29 12:50 UTC (permalink / raw)
To: andrew; +Cc: netdev
In-Reply-To: <20161028185236.GA18361@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Fri, 28 Oct 2016 20:52:36 +0200
> During the merge window, you didn't close net-next. Trying something
> new.
>
> We are now at v4.9-rc2, yet net-next is still based on 4.8.0. Is this
> also something new you are trying? Or do you still plan to rebase to
> an -rcX at some point?
I plan to rebase the next time I ask Linus to pull 'net' and he takes
it in, which should be this weekend.
^ permalink raw reply
* [PATCH 1/4] isdn/eicon: remove unused argument in DBG_ERR call
From: Nicolas Iooss @ 2016-10-29 12:56 UTC (permalink / raw)
To: Armin Schindler, Karsten Keil; +Cc: netdev, linux-kernel, Nicolas Iooss
diva_um_idi_read() can call DBG_ERR with 3 format arguments but using a
format string which only uses 2 of them. Remove the last one.
This bug has been found by adding a __printf attribute to
myDbgPrint_...() functions. As this addition leads the compiler to
report a lot of -Wformat warnings (for example the compiler complains
when "%08x" is used to format a pointer, as it is done with all usages
of "E(%08x)" in um_idi.c), this patch does not add any __printf
attribute.
This patch has only been compile-tested.
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
---
drivers/isdn/hardware/eicon/um_idi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/eicon/um_idi.c b/drivers/isdn/hardware/eicon/um_idi.c
index e1519718ce67..13ef38fa6cb0 100644
--- a/drivers/isdn/hardware/eicon/um_idi.c
+++ b/drivers/isdn/hardware/eicon/um_idi.c
@@ -351,7 +351,7 @@ int diva_um_idi_read(void *entity,
Not enough space to read message
*/
DBG_ERR(("A: A(%d) E(%08x) read small buffer",
- a->adapter_nr, e, ret));
+ a->adapter_nr, e));
diva_os_leave_spin_lock(&adapter_lock, &old_irql,
"read");
return (-2);
--
2.10.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