* [PATCH 4/4 net-next] net: bcmgenet: rename bcmgenet_hw_params->bds_cnt and GENET_DEFAULT_BD_CNT
From: Petri Gynther @ 2014-12-04 4:12 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli
bcmgenet_hw_params->bds_cnt and GENET_DEFAULT_BD_CNT are used only in Tx init.
Rename them accordingly:
- bcmgenet_hw_params->bds_cnt => bcmgenet_hw_params->tx_bds_per_q
- GENET_DEFAULT_BD_CNT => GENET_Q16_TX_BD_CNT
Signed-off-by: Petri Gynther <pgynther@google.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 29 +++++++++++++-------------
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 2 +-
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 8ef851c..c7a0816 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -53,8 +53,8 @@
/* Default highest priority queue for multi queue support */
#define GENET_Q0_PRIORITY 0
-#define GENET_DEFAULT_BD_CNT \
- (TOTAL_DESC - priv->hw_params->tx_queues * priv->hw_params->bds_cnt)
+#define GENET_Q16_TX_BD_CNT \
+ (TOTAL_DESC - priv->hw_params->tx_queues * priv->hw_params->tx_bds_per_q)
#define RX_BUF_LENGTH 2048
#define SKB_ALIGNMENT 32
@@ -1783,7 +1783,7 @@ static int bcmgenet_init_rx_ring(struct bcmgenet_priv *priv,
* with queue 0 being the highest priority queue.
*
* Queue 16 is the default Tx queue with
- * GENET_DEFAULT_BD_CNT = 256 - 4 * 32 = 128 descriptors.
+ * GENET_Q16_TX_BD_CNT = 256 - 4 * 32 = 128 descriptors.
*
* The transmit control block pool is then partitioned as follows:
* - Tx queue 0 uses tx_cbs[0..31]
@@ -1812,9 +1812,9 @@ static void bcmgenet_init_tx_queues(struct net_device *dev)
/* Initialize Tx priority queues */
for (i = 0; i < priv->hw_params->tx_queues; i++) {
- bcmgenet_init_tx_ring(priv, i, priv->hw_params->bds_cnt,
- i * priv->hw_params->bds_cnt,
- (i + 1) * priv->hw_params->bds_cnt);
+ bcmgenet_init_tx_ring(priv, i, priv->hw_params->tx_bds_per_q,
+ i * priv->hw_params->tx_bds_per_q,
+ (i + 1) * priv->hw_params->tx_bds_per_q);
ring_cfg |= (1 << i);
dma_ctrl |= (1 << (i + DMA_RING_BUF_EN_SHIFT));
dma_priority[DMA_PRIO_REG_INDEX(i)] |=
@@ -1822,9 +1822,9 @@ static void bcmgenet_init_tx_queues(struct net_device *dev)
}
/* Initialize Tx default queue 16 */
- bcmgenet_init_tx_ring(priv, DESC_INDEX, GENET_DEFAULT_BD_CNT,
+ bcmgenet_init_tx_ring(priv, DESC_INDEX, GENET_Q16_TX_BD_CNT,
priv->hw_params->tx_queues *
- priv->hw_params->bds_cnt,
+ priv->hw_params->tx_bds_per_q,
TOTAL_DESC);
ring_cfg |= (1 << DESC_INDEX);
dma_ctrl |= (1 << (DESC_INDEX + DMA_RING_BUF_EN_SHIFT));
@@ -2428,8 +2428,8 @@ static const struct net_device_ops bcmgenet_netdev_ops = {
static struct bcmgenet_hw_params bcmgenet_hw_params[] = {
[GENET_V1] = {
.tx_queues = 0,
+ .tx_bds_per_q = 0,
.rx_queues = 0,
- .bds_cnt = 0,
.bp_in_en_shift = 16,
.bp_in_mask = 0xffff,
.hfb_filter_cnt = 16,
@@ -2441,8 +2441,8 @@ static struct bcmgenet_hw_params bcmgenet_hw_params[] = {
},
[GENET_V2] = {
.tx_queues = 4,
+ .tx_bds_per_q = 32,
.rx_queues = 4,
- .bds_cnt = 32,
.bp_in_en_shift = 16,
.bp_in_mask = 0xffff,
.hfb_filter_cnt = 16,
@@ -2457,8 +2457,8 @@ static struct bcmgenet_hw_params bcmgenet_hw_params[] = {
},
[GENET_V3] = {
.tx_queues = 4,
+ .tx_bds_per_q = 32,
.rx_queues = 4,
- .bds_cnt = 32,
.bp_in_en_shift = 17,
.bp_in_mask = 0x1ffff,
.hfb_filter_cnt = 48,
@@ -2473,8 +2473,8 @@ static struct bcmgenet_hw_params bcmgenet_hw_params[] = {
},
[GENET_V4] = {
.tx_queues = 4,
+ .tx_bds_per_q = 32,
.rx_queues = 4,
- .bds_cnt = 32,
.bp_in_en_shift = 17,
.bp_in_mask = 0x1ffff,
.hfb_filter_cnt = 48,
@@ -2552,14 +2552,15 @@ static void bcmgenet_set_hw_params(struct bcmgenet_priv *priv)
#endif
pr_debug("Configuration for version: %d\n"
- "TXq: %1d, RXq: %1d, BDs: %1d\n"
+ "TXq: %1d, TXqBDs: %1d, RXq: %1d\n"
"BP << en: %2d, BP msk: 0x%05x\n"
"HFB count: %2d, QTAQ msk: 0x%05x\n"
"TBUF: 0x%04x, HFB: 0x%04x, HFBreg: 0x%04x\n"
"RDMA: 0x%05x, TDMA: 0x%05x\n"
"Words/BD: %d\n",
priv->version,
- params->tx_queues, params->rx_queues, params->bds_cnt,
+ params->tx_queues, params->tx_bds_per_q,
+ params->rx_queues,
params->bp_in_en_shift, params->bp_in_mask,
params->hfb_filter_cnt, params->qtag_mask,
params->tbuf_offset, params->hfb_offset,
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
index b36ddec..3a8a90f 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -503,8 +503,8 @@ enum bcmgenet_version {
*/
struct bcmgenet_hw_params {
u8 tx_queues;
+ u8 tx_bds_per_q;
u8 rx_queues;
- u8 bds_cnt;
u8 bp_in_en_shift;
u32 bp_in_mask;
u8 hfb_filter_cnt;
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH 3/4 net-next] net: bcmgenet: precalculate TxCB->bd_addr
From: Petri Gynther @ 2014-12-04 4:11 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli
There is 1-to-1 mapping between TxCBs and TxBDs. Precalculate TxCB->bd_addr
once in bcmgenet_init_dma() instead of doing it over and over needlessly in
bcmgenet_get_txcb().
Signed-off-by: Petri Gynther <pgynther@google.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index eba310a..8ef851c 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -919,7 +919,7 @@ static struct enet_cb *bcmgenet_get_txcb(struct bcmgenet_priv *priv,
tx_cb_ptr = ring->cbs;
tx_cb_ptr += ring->write_ptr - ring->cb_ptr;
- tx_cb_ptr->bd_addr = priv->tx_bds + ring->write_ptr * DMA_DESC_SIZE;
+
/* Advancing local write pointer */
if (ring->write_ptr == ring->end_ptr)
ring->write_ptr = ring->cb_ptr;
@@ -1920,6 +1920,8 @@ static void bcmgenet_fini_dma(struct bcmgenet_priv *priv)
static int bcmgenet_init_dma(struct bcmgenet_priv *priv)
{
int ret;
+ unsigned int i;
+ struct enet_cb *cb;
netif_dbg(priv, hw, priv->dev, "bcmgenet: init_edma\n");
@@ -1946,6 +1948,11 @@ static int bcmgenet_init_dma(struct bcmgenet_priv *priv)
return -ENOMEM;
}
+ for (i = 0; i < priv->num_tx_bds; i++) {
+ cb = priv->tx_cbs + i;
+ cb->bd_addr = priv->tx_bds + i * DMA_DESC_SIZE;
+ }
+
/* Initialize Tx queues */
bcmgenet_init_tx_queues(priv->dev);
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH 2/4 net-next] net: bcmgenet: rework Tx queue init
From: Petri Gynther @ 2014-12-04 4:11 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli
1. Rename bcmgenet_init_multiq() to bcmgenet_init_tx_queues()
2. Move Tx default queue init inside bcmgenet_init_tx_queues()
Signed-off-by: Petri Gynther <pgynther@google.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 82 +++++++++++---------------
1 file changed, 36 insertions(+), 46 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 78ab733..eba310a 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1776,78 +1776,74 @@ static int bcmgenet_init_rx_ring(struct bcmgenet_priv *priv,
return ret;
}
-/* init multi xmit queues, only available for GENET2+
- * the queue is partitioned as follows:
+/*
+ * Initialize Tx queues
*
- * queue 0 - 3 is priority based, each one has 32 descriptors,
+ * Queues 0-3 are priority-based, each one has 32 descriptors,
* with queue 0 being the highest priority queue.
*
- * queue 16 is the default tx queue with GENET_DEFAULT_BD_CNT
- * descriptors: 256 - (number of tx queues * bds per queues) = 128
- * descriptors.
+ * Queue 16 is the default Tx queue with
+ * GENET_DEFAULT_BD_CNT = 256 - 4 * 32 = 128 descriptors.
*
- * The transmit control block pool is then partitioned as following:
- * - tx_cbs[0...127] are for queue 16
- * - tx_ring_cbs[0] points to tx_cbs[128..159]
- * - tx_ring_cbs[1] points to tx_cbs[160..191]
- * - tx_ring_cbs[2] points to tx_cbs[192..223]
- * - tx_ring_cbs[3] points to tx_cbs[224..255]
+ * The transmit control block pool is then partitioned as follows:
+ * - Tx queue 0 uses tx_cbs[0..31]
+ * - Tx queue 1 uses tx_cbs[32..63]
+ * - Tx queue 2 uses tx_cbs[64..95]
+ * - Tx queue 3 uses tx_cbs[96..127]
+ * - Tx queue 16 uses tx_cbs[128..255]
*/
-static void bcmgenet_init_multiq(struct net_device *dev)
+static void bcmgenet_init_tx_queues(struct net_device *dev)
{
struct bcmgenet_priv *priv = netdev_priv(dev);
- unsigned int i, dma_enable;
- u32 reg, dma_ctrl, ring_cfg = 0;
+ u32 i, dma_enable;
+ u32 dma_ctrl, ring_cfg;
u32 dma_priority[3] = {0, 0, 0};
- if (!netif_is_multiqueue(dev)) {
- netdev_warn(dev, "called with non multi queue aware HW\n");
- return;
- }
-
dma_ctrl = bcmgenet_tdma_readl(priv, DMA_CTRL);
dma_enable = dma_ctrl & DMA_EN;
dma_ctrl &= ~DMA_EN;
bcmgenet_tdma_writel(priv, dma_ctrl, DMA_CTRL);
+ dma_ctrl = 0;
+ ring_cfg = 0;
+
/* Enable strict priority arbiter mode */
bcmgenet_tdma_writel(priv, DMA_ARBITER_SP, DMA_ARB_CTRL);
+ /* Initialize Tx priority queues */
for (i = 0; i < priv->hw_params->tx_queues; i++) {
- /* first 64 tx_cbs are reserved for default tx queue
- * (ring 16)
- */
bcmgenet_init_tx_ring(priv, i, priv->hw_params->bds_cnt,
i * priv->hw_params->bds_cnt,
(i + 1) * priv->hw_params->bds_cnt);
-
- /* Configure ring as descriptor ring and setup priority */
- ring_cfg |= 1 << i;
- dma_ctrl |= 1 << (i + DMA_RING_BUF_EN_SHIFT);
-
+ ring_cfg |= (1 << i);
+ dma_ctrl |= (1 << (i + DMA_RING_BUF_EN_SHIFT));
dma_priority[DMA_PRIO_REG_INDEX(i)] |=
((GENET_Q0_PRIORITY + i) << DMA_PRIO_REG_SHIFT(i));
}
- /* Set ring 16 priority and program the hardware registers */
+ /* Initialize Tx default queue 16 */
+ bcmgenet_init_tx_ring(priv, DESC_INDEX, GENET_DEFAULT_BD_CNT,
+ priv->hw_params->tx_queues *
+ priv->hw_params->bds_cnt,
+ TOTAL_DESC);
+ ring_cfg |= (1 << DESC_INDEX);
+ dma_ctrl |= (1 << (DESC_INDEX + DMA_RING_BUF_EN_SHIFT));
dma_priority[DMA_PRIO_REG_INDEX(DESC_INDEX)] |=
((GENET_Q0_PRIORITY + priv->hw_params->tx_queues) <<
DMA_PRIO_REG_SHIFT(DESC_INDEX));
+
+ /* Set Tx queue priorities */
bcmgenet_tdma_writel(priv, dma_priority[0], DMA_PRIORITY_0);
bcmgenet_tdma_writel(priv, dma_priority[1], DMA_PRIORITY_1);
bcmgenet_tdma_writel(priv, dma_priority[2], DMA_PRIORITY_2);
- /* Enable rings */
- reg = bcmgenet_tdma_readl(priv, DMA_RING_CFG);
- reg |= ring_cfg;
- bcmgenet_tdma_writel(priv, reg, DMA_RING_CFG);
+ /* Enable Tx queues */
+ bcmgenet_tdma_writel(priv, ring_cfg, DMA_RING_CFG);
- /* Configure ring as descriptor ring and re-enable DMA if enabled */
- reg = bcmgenet_tdma_readl(priv, DMA_CTRL);
- reg |= dma_ctrl;
+ /* Enable Tx DMA */
if (dma_enable)
- reg |= DMA_EN;
- bcmgenet_tdma_writel(priv, reg, DMA_CTRL);
+ dma_ctrl |= DMA_EN;
+ bcmgenet_tdma_writel(priv, dma_ctrl, DMA_CTRL);
}
static int bcmgenet_dma_teardown(struct bcmgenet_priv *priv)
@@ -1950,14 +1946,8 @@ static int bcmgenet_init_dma(struct bcmgenet_priv *priv)
return -ENOMEM;
}
- /* initialize multi xmit queue */
- bcmgenet_init_multiq(priv->dev);
-
- /* initialize special ring 16 */
- bcmgenet_init_tx_ring(priv, DESC_INDEX, GENET_DEFAULT_BD_CNT,
- priv->hw_params->tx_queues *
- priv->hw_params->bds_cnt,
- TOTAL_DESC);
+ /* Initialize Tx queues */
+ bcmgenet_init_tx_queues(priv->dev);
return 0;
}
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH 1/4 net-next] net: bcmgenet: bcmgenet_init_tx_ring() cleanup
From: Petri Gynther @ 2014-12-04 4:11 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli
Signed-off-by: Petri Gynther <pgynther@google.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index f2fadb0..78ab733 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1679,17 +1679,16 @@ static int init_umac(struct bcmgenet_priv *priv)
return 0;
}
-/* Initialize all house-keeping variables for a TX ring, along
- * with corresponding hardware registers
+/*
+ * Initialize a Tx ring along with corresponding hardware registers.
*/
static void bcmgenet_init_tx_ring(struct bcmgenet_priv *priv,
unsigned int index, unsigned int size,
- unsigned int write_ptr, unsigned int end_ptr)
+ unsigned int start_ptr, unsigned int end_ptr)
{
struct bcmgenet_tx_ring *ring = &priv->tx_rings[index];
u32 words_per_bd = WORDS_PER_BD(priv);
u32 flow_period_val = 0;
- unsigned int first_bd;
spin_lock_init(&ring->lock);
ring->index = index;
@@ -1702,12 +1701,12 @@ static void bcmgenet_init_tx_ring(struct bcmgenet_priv *priv,
ring->int_enable = bcmgenet_tx_ring_int_enable;
ring->int_disable = bcmgenet_tx_ring_int_disable;
}
- ring->cbs = priv->tx_cbs + write_ptr;
+ ring->cbs = priv->tx_cbs + start_ptr;
ring->size = size;
ring->c_index = 0;
ring->free_bds = size;
- ring->write_ptr = write_ptr;
- ring->cb_ptr = write_ptr;
+ ring->write_ptr = start_ptr;
+ ring->cb_ptr = start_ptr;
ring->end_ptr = end_ptr - 1;
ring->prod_index = 0;
@@ -1718,22 +1717,18 @@ static void bcmgenet_init_tx_ring(struct bcmgenet_priv *priv,
bcmgenet_tdma_ring_writel(priv, index, 0, TDMA_PROD_INDEX);
bcmgenet_tdma_ring_writel(priv, index, 0, TDMA_CONS_INDEX);
bcmgenet_tdma_ring_writel(priv, index, 1, DMA_MBUF_DONE_THRESH);
- /* Disable rate control for now */
bcmgenet_tdma_ring_writel(priv, index, flow_period_val,
TDMA_FLOW_PERIOD);
- /* Unclassified traffic goes to ring 16 */
bcmgenet_tdma_ring_writel(priv, index,
((size << DMA_RING_SIZE_SHIFT) |
RX_BUF_LENGTH), DMA_RING_BUF_SIZE);
- first_bd = write_ptr;
-
/* Set start and end address, read and write pointers */
- bcmgenet_tdma_ring_writel(priv, index, first_bd * words_per_bd,
+ bcmgenet_tdma_ring_writel(priv, index, start_ptr * words_per_bd,
DMA_START_ADDR);
- bcmgenet_tdma_ring_writel(priv, index, first_bd * words_per_bd,
+ bcmgenet_tdma_ring_writel(priv, index, start_ptr * words_per_bd,
TDMA_READ_PTR);
- bcmgenet_tdma_ring_writel(priv, index, first_bd,
+ bcmgenet_tdma_ring_writel(priv, index, start_ptr * words_per_bd,
TDMA_WRITE_PTR);
bcmgenet_tdma_ring_writel(priv, index, end_ptr * words_per_bd - 1,
DMA_END_ADDR);
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* Re: What's the concern about setting irq thread's policy as SCHED_FIFO
From: Qin Chuanyu @ 2014-12-04 3:12 UTC (permalink / raw)
To: Rick Jones, netdev; +Cc: linux-kernel
In-Reply-To: <547F3F92.2050501@hp.com>
On 2014/12/4 0:51, Rick Jones wrote:
> On 12/03/2014 12:06 AM, Qin Chuanyu wrote:
>> I am doing network performance test under suse11sp3 and intel 82599 nic,
>> Becasuse the softirq is out of schedule policy's control, so netserver
>> thread couldn't always get 100% cpu usage, then packet dropped in kernel
>> udp socket's receive queue.
>>
>> In order to get a stable result, I did some patch in ixgbe driver and
>> then use irq_thread instead of softirq to handle rx.
>> It seems work well, but irq_thread's SCHED_FIFO schedule policy cause
>> that when the cpu is limited, netserver couldn't work at all.
>
> I cannot speak to any scheduling issues/questions, but can ask if you
> tried binding netserver to a CPU other than the one servicing the
> interrupts via the -T option on the netperf command line:
>
> netperf -T <netperfCPU>,<netserverCPU> ...
>
> http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#index-g_t_002dT_002c-Global-41
>
Yes, I had done this try, the irq_thread and netserver worked well
without competition after binding them separately.
I also had tried this test case in kernel 3.10, and without binding
irq_thread and netserver work well separately.
So, the question is:
3.10: irq_thread netserver good
3.0.93: irq_thread netserver bad(compete single cpu)
normal thread in both kernel version is OK.
There must be a schedule policy change lead to this difference.
Could anyone give some hint?
>
> happy benchnmarking,
>
> rick jones
>
>>
>> So I change the irq_thread's schedule policy from SCHED_FIFO to
>> SCHED_NORMAL, then the irq_thread could share the cpu usage with
>> netserver thread.
>>
>> the question is:
>> What's the concrete reason about setting irq thread's policy as
>> SCHED_FIFO?
>> Except the priority affecting the cpu usage, any function would be
>> broken if irq thread change to SCHED_NORMAL?
>>
^ permalink raw reply
* Re: [PATCH] net: less interrupt masking in NAPI
From: Yang Yingliang @ 2014-12-04 3:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, willemb
In-Reply-To: <1417661505.22424.1.camel@edumazet-glaptop2.roam.corp.google.com>
On 2014/12/4 10:51, Eric Dumazet wrote:
> On Thu, 2014-12-04 at 10:10 +0800, Yang Yingliang wrote:
>> On 2014/12/3 19:52, Eric Dumazet wrote:
>>> On Wed, 2014-12-03 at 17:26 +0800, Yang Yingliang wrote:
>>>
>>>> Before this patch, when a large network flow arrives, some other processes
>>>> response slowly or even don't response because the cpu is dealing with softirq.
>>>>
>>>> After this patch, under pressure, much more softirq is doing in ksoftirqd. The other
>>>> processes be scheduled.
>>>>
>>>> My system has dual core.
>>>
>>> Which NIC driver are you using ?
>>>
>> The driver we developed ourself, it's not upstreamed.
>
> Is it a NAPI driver ?
Yes.
>
> Quite frankly this patch is not a stable candidate, as it was a
> performance improvement, with some regressions in a couple of drivers.
>
OK, thanks for your reply.
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2 tuntap: Increase the number of queues in tun.
From: Jason Wang @ 2014-12-04 2:55 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Pankaj Gupta, linux-kernel, netdev, davem, dgibson, vfalico,
edumazet, vyasevic, hkchu, wuzhy, xemul, therbert, bhutchings,
xii, stephen, jiri, sergei.shtylyov
In-Reply-To: <20141203095210.GC9487@redhat.com>
On Wed, Dec 3, 2014 at 5:52 PM, Michael S. Tsirkin <mst@redhat.com>
wrote:
> On Wed, Dec 03, 2014 at 12:49:37PM +0530, Pankaj Gupta wrote:
>> Networking under kvm works best if we allocate a per-vCPU RX and TX
>> queue in a virtual NIC. This requires a per-vCPU queue on the host
>> side.
>>
>> It is now safe to increase the maximum number of queues.
>> Preceding patche: 'net: allow large number of rx queues'
>
> s/patche/patch/
>
>> made sure this won't cause failures due to high order memory
>> allocations. Increase it to 256: this is the max number of vCPUs
>> KVM supports.
>>
>> Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
>> Reviewed-by: David Gibson <dgibson@redhat.com>
>
> Hmm it's kind of nasty that each tun device is now using x16 memory.
> Maybe we should look at using a flex array instead, and removing the
> limitation altogether (e.g. make it INT_MAX)?
But this only happens when IFF_MULTIQUEUE were used.
And core has vmalloc() fallback.
So probably not a big issue?
>
>
>
>> ---
>> drivers/net/tun.c | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index e3fa65a..a19dc5f8 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -113,10 +113,11 @@ struct tap_filter {
>> unsigned char addr[FLT_EXACT_COUNT][ETH_ALEN];
>> };
>>
>> -/* DEFAULT_MAX_NUM_RSS_QUEUES were chosen to let the rx/tx queues
>> allocated for
>> - * the netdevice to be fit in one page. So we can make sure the
>> success of
>> - * memory allocation. TODO: increase the limit. */
>> -#define MAX_TAP_QUEUES DEFAULT_MAX_NUM_RSS_QUEUES
>> +/* MAX_TAP_QUEUES 256 is chosen to allow rx/tx queues to be equal
>> + * to max number of vCPUS in guest. Also, we are making sure here
>> + * queue memory allocation do not fail.
>
> It's not queue memory allocation anymore, is it?
> I would say "
> This also helps the tfiles field fit in 4K, so the whole tun
> device only needs an order-1 allocation.
> "
>
>> + */
>> +#define MAX_TAP_QUEUES 256
>> #define MAX_TAP_FLOWS 4096
>>
>> #define TUN_FLOW_EXPIRE (3 * HZ)
>> --
>> 1.8.3.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: less interrupt masking in NAPI
From: Eric Dumazet @ 2014-12-04 2:51 UTC (permalink / raw)
To: Yang Yingliang; +Cc: David Miller, netdev, willemb
In-Reply-To: <547FC2A1.60105@huawei.com>
On Thu, 2014-12-04 at 10:10 +0800, Yang Yingliang wrote:
> On 2014/12/3 19:52, Eric Dumazet wrote:
> > On Wed, 2014-12-03 at 17:26 +0800, Yang Yingliang wrote:
> >
> >> Before this patch, when a large network flow arrives, some other processes
> >> response slowly or even don't response because the cpu is dealing with softirq.
> >>
> >> After this patch, under pressure, much more softirq is doing in ksoftirqd. The other
> >> processes be scheduled.
> >>
> >> My system has dual core.
> >
> > Which NIC driver are you using ?
> >
> The driver we developed ourself, it's not upstreamed.
Is it a NAPI driver ?
Quite frankly this patch is not a stable candidate, as it was a
performance improvement, with some regressions in a couple of drivers.
^ permalink raw reply
* [PATCH net-next] r8152: redefine REALTEK_USB_DEVICE
From: Hayes Wang @ 2014-12-04 2:43 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
Redefine REALTEK_USB_DEVICE for the desired USB interface for probe().
There are three USB interfaces for the device. USB_CLASS_COMM and
USB_CLASS_CDC_DATA are for ECM mode (config #2). USB_CLASS_VENDOR_SPEC
is for the vendor mode (config #1). However, we are not interesting
in USB_CLASS_CDC_DATA for probe(), so redefine REALTEK_USB_DEVICE
to ignore the USB interface class of USB_CLASS_CDC_DATA.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4a9ece0..2d1c77e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -24,6 +24,7 @@
#include <net/ip6_checksum.h>
#include <uapi/linux/mdio.h>
#include <linux/mdio.h>
+#include <linux/usb/cdc.h>
/* Version Information */
#define DRIVER_VERSION "v1.07.0 (2014/10/09)"
@@ -466,9 +467,6 @@ enum rtl8152_flags {
#define MCU_TYPE_PLA 0x0100
#define MCU_TYPE_USB 0x0000
-#define REALTEK_USB_DEVICE(vend, prod) \
- USB_DEVICE_INTERFACE_CLASS(vend, prod, USB_CLASS_VENDOR_SPEC)
-
struct tally_counter {
__le64 tx_packets;
__le64 rx_packets;
@@ -3915,11 +3913,27 @@ static void rtl8152_disconnect(struct usb_interface *intf)
}
}
+#define REALTEK_USB_DEVICE(vend, prod) \
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
+ USB_DEVICE_ID_MATCH_INT_CLASS, \
+ .idVendor = (vend), \
+ .idProduct = (prod), \
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC \
+}, \
+{ \
+ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO | \
+ USB_DEVICE_ID_MATCH_DEVICE, \
+ .idVendor = (vend), \
+ .idProduct = (prod), \
+ .bInterfaceClass = USB_CLASS_COMM, \
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET, \
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE
+
/* table of devices that work with this driver */
static struct usb_device_id rtl8152_table[] = {
- {USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)},
- {USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)},
- {USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)},
{}
};
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] net: less interrupt masking in NAPI
From: Yang Yingliang @ 2014-12-04 2:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, willemb
In-Reply-To: <1417607546.5303.133.camel@edumazet-glaptop2.roam.corp.google.com>
On 2014/12/3 19:52, Eric Dumazet wrote:
> On Wed, 2014-12-03 at 17:26 +0800, Yang Yingliang wrote:
>
>> Before this patch, when a large network flow arrives, some other processes
>> response slowly or even don't response because the cpu is dealing with softirq.
>>
>> After this patch, under pressure, much more softirq is doing in ksoftirqd. The other
>> processes be scheduled.
>>
>> My system has dual core.
>
> Which NIC driver are you using ?
>
The driver we developed ourself, it's not upstreamed.
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Jesse Gross @ 2014-12-04 1:51 UTC (permalink / raw)
To: Thomas Graf
Cc: Michael S. Tsirkin, Du, Fan, Jason Wang, netdev@vger.kernel.org,
davem@davemloft.net, fw@strlen.de, dev@openvswitch.org,
Pravin Shelar
In-Reply-To: <20141204011515.GA15666@casper.infradead.org>
On Wed, Dec 3, 2014 at 5:15 PM, Thomas Graf <tgraf@suug.ch> wrote:
> On 12/03/14 at 04:54pm, Jesse Gross wrote:
>> I don't think that we actually need a bit. I would expect that ICMP
>> generation to be coupled with routing (although this requires being
>> able to know what the ultimate MTU is at the time of routing the inner
>> packet). If that's the case, you just need to steer between L2 and L3
>> processing in the same way that you would today and ICMP would just
>> come in the right cases.
>
> I think the MTU awareness is solveable but how do you steer between
> L2 and L3? How do you differentiate between an L3 ACL rule in L2 mode
> and an actual L3 based forward? dec_ttl? This is what drove me to
> the user controlled bit and it became appealing as it allows to
> enable/disable PMTU per guest or even per flow/route.
I think it depends on where you put the PMTU check. If routing is
happening in OVS where it is decomposed in several discrete actions
like set MAC and decrement TTL then perhaps there is another explicit
action to check the MTU. If it is happening in the context of the IP
stack, then ICMP generation occurs automatically and if you get that
if you write a flow to send a packet there. In each case, it seems
like a flow would be steering you by way of an action to do routing so
you would have fine grained control. I don't see this as conflicting
with L3 ACLs in an L2 context in the same way that you don't have to
automatically decrement the TTL.
^ permalink raw reply
* Re: kernel panic receiving flooded VXLAN traffic with OVS
From: Jay Vosburgh @ 2014-12-04 1:45 UTC (permalink / raw)
To: netdev, discuss; +Cc: Pravin Shelar, Jesse Gross
In-Reply-To: <19014.1415325508@famine>
Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
> I am able to reproduce a kernel panic on an system using
>openvswitch when receiving VXLAN traffic under a very specific set of
>circumstances. This occurs with a recent net-next as well as an Ubuntu
>3.13 kernel. I'm not sure if the error lies in OVS, GRO, or elsewhere.
>
> In summary, when the system receives multiple VXLAN encapsulated
>TCP segments for a different system (not intended for local reception)
>that are from the middle of an active connection (received due to a switch
>flood), and are tagged to a VLAN not configured on the local host, then
>the system panics in skb_segment when OVS calls __skb_gso_segment on the
>GRO skb prior to performing an upcall to user space.
>
> The panic occurs in skbuff.c:skb_segment(), at the BUG_ON around
>line 3036:
>
>struct sk_buff *skb_segment(struct sk_buff *head_skb,
> netdev_features_t features)
>{
>[...]
> skb_shinfo(nskb)->tx_flags = skb_shinfo(head_skb)->tx_flags &
> SKBTX_SHARED_FRAG;
>
> while (pos < offset + len) {
> if (i >= nfrags) {
> BUG_ON(skb_headlen(list_skb));
>
> i = 0;
>
>
> The BUG_ON triggers because the skbs that have been GRO
>accumulated are partially or entirely linear, depending upon the receiving
>network device (sky2 is partial, enic is entire). The receive buffers end
>up being linear evidently because the mtu is set to 9000, and
>__netdev_alloc_skb calls __alloc_skb (and thus kmalloc) instead of
>__netdev_alloc_frag followed by build_skb.
>
> The foreign-VLAN VXLAN TCP segments are not processed as normal
>VXLAN traffic, as there is no listener on the VLAN in question, so once
>GRO processes them, they are sent directly to ovs_vport_receive. The
>panic stack appears as follows:
I've worked out some more details on this with regards to the
cause.
There seems to be a mismatch between GRO and the packet receive
processing. GRO only looks at the receiving port number in order to
trigger VXLAN GRO accumulation (which will in turn perform TCP
accumulation on the encapsulated segment). For the panicking case, the
packet receive processing doesn't deliver the GRO skb to VXLAN because
there is no VXLAN listener on the foreign VLAN.
The GRO skb is not processed through iptunnel_pull_header by
vxlan_udp_encap_recv, so the GRO skb is left with the skb header
pointing to the UDP header, not the inner TCP header. Note that second
and later skbs within the GRO skb have their headers pointing to the
inner TCP header.
Then, when ovs_dp_upcall later ends up in inet_gso_segment, it
passes the GRO skb to udp4_ufo_fragment, not tcp_gso_segment.
GRO and the skb_segment call from ovs_dp_upcall appear to work
fine on TCP-in-VXLAN segments that do pass through the VXLAN receive
processing.
I'm not sure how best to resolve this; adding a check to the GRO
processing that an skb destined for the VXLAN port would actually be
received by VXLAN sounds like a possible solution, but that doesn't seem
to be simple to implement (because the skb->dev at the time GRO runs may
not match what it becomes later if the VXLAN runs on a VLAN).
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Thomas Graf @ 2014-12-04 1:15 UTC (permalink / raw)
To: Jesse Gross
Cc: Michael S. Tsirkin, Du, Fan, Jason Wang, netdev@vger.kernel.org,
davem@davemloft.net, fw@strlen.de, dev@openvswitch.org,
Pravin Shelar
In-Reply-To: <CAEP_g=-y_-=r+BHk3VfzxMNwH=B-26DvQrzQ7gkKG8fDG7Mx3g@mail.gmail.com>
On 12/03/14 at 04:54pm, Jesse Gross wrote:
> I don't think that we actually need a bit. I would expect that ICMP
> generation to be coupled with routing (although this requires being
> able to know what the ultimate MTU is at the time of routing the inner
> packet). If that's the case, you just need to steer between L2 and L3
> processing in the same way that you would today and ICMP would just
> come in the right cases.
I think the MTU awareness is solveable but how do you steer between
L2 and L3? How do you differentiate between an L3 ACL rule in L2 mode
and an actual L3 based forward? dec_ttl? This is what drove me to
the user controlled bit and it became appealing as it allows to
enable/disable PMTU per guest or even per flow/route.
^ permalink raw reply
* [PATCH] e1000e / igb / PM: Eliminate CONFIG_PM_RUNTIME
From: Rafael J. Wysocki @ 2014-12-04 1:15 UTC (permalink / raw)
To: e1000-devel
Cc: Jeff Kirsher, netdev, Linux NICS, Jesse Brandeburg, Bruce Allan,
Linux Kernel Mailing List, Linux PM list
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME within #ifdef blocks depending on
CONFIG_PM may be dropped now.
Do that in the e1000e and igb network drivers.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) which is only in linux-next at the moment (via the
linux-pm tree).
Please let me know if it is OK to take this one into linux-pm.
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 --
drivers/net/ethernet/intel/igb/igb_main.c | 6 +-----
2 files changed, 1 insertion(+), 7 deletions(-)
Index: linux-pm/drivers/net/ethernet/intel/e1000e/netdev.c
===================================================================
--- linux-pm.orig/drivers/net/ethernet/intel/e1000e/netdev.c
+++ linux-pm/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6372,7 +6372,6 @@ static int e1000e_pm_resume(struct devic
}
#endif /* CONFIG_PM_SLEEP */
-#ifdef CONFIG_PM_RUNTIME
static int e1000e_pm_runtime_idle(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
@@ -6432,7 +6431,6 @@ static int e1000e_pm_runtime_suspend(str
return 0;
}
-#endif /* CONFIG_PM_RUNTIME */
#endif /* CONFIG_PM */
static void e1000_shutdown(struct pci_dev *pdev)
Index: linux-pm/drivers/net/ethernet/intel/igb/igb_main.c
===================================================================
--- linux-pm.orig/drivers/net/ethernet/intel/igb/igb_main.c
+++ linux-pm/drivers/net/ethernet/intel/igb/igb_main.c
@@ -186,11 +186,9 @@ static int igb_pci_enable_sriov(struct p
static int igb_suspend(struct device *);
#endif
static int igb_resume(struct device *);
-#ifdef CONFIG_PM_RUNTIME
static int igb_runtime_suspend(struct device *dev);
static int igb_runtime_resume(struct device *dev);
static int igb_runtime_idle(struct device *dev);
-#endif
static const struct dev_pm_ops igb_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(igb_suspend, igb_resume)
SET_RUNTIME_PM_OPS(igb_runtime_suspend, igb_runtime_resume,
@@ -7441,7 +7439,6 @@ static int igb_resume(struct device *dev
return 0;
}
-#ifdef CONFIG_PM_RUNTIME
static int igb_runtime_idle(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
@@ -7478,8 +7475,7 @@ static int igb_runtime_resume(struct dev
{
return igb_resume(dev);
}
-#endif /* CONFIG_PM_RUNTIME */
-#endif
+#endif /* CONFIG_PM */
static void igb_shutdown(struct pci_dev *pdev)
{
^ permalink raw reply
* [PATCH net-next] net: avoid two atomic operations in fast clones
From: Eric Dumazet @ 2014-12-04 1:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Chris Mason, Sabrina Dubroca, Vijay Subramanian
From: Eric Dumazet <edumazet@google.com>
Commit ce1a4ea3f125 ("net: avoid one atomic operation in skb_clone()")
took the wrong way to save one atomic operation.
It is actually possible to avoid two atomic operations, if we
do not change skb->fclone values, and only rely on clone_ref
content to signal if the clone is available or not.
skb_clone() can simply use the fast clone if clone_ref is 1.
kfree_skbmem() can avoid the atomic_dec_and_test() if clone_ref is 1.
Note that because we usually free the clone before the original skb,
this particular attempt is only done for the original skb to have better
branch prediction.
SKB_FCLONE_FREE is removed.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Chris Mason <clm@fb.com>
Cc: Sabrina Dubroca <sd@queasysnail.net>
Cc: Vijay Subramanian <subramanian.vijay@gmail.com>
---
include/linux/skbuff.h | 3 +--
net/core/skbuff.c | 35 ++++++++++++++++++-----------------
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 7691ad5b4771..27b64d5f7c94 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -344,7 +344,6 @@ enum {
SKB_FCLONE_UNAVAILABLE, /* skb has no fclone (from head_cache) */
SKB_FCLONE_ORIG, /* orig skb (from fclone_cache) */
SKB_FCLONE_CLONE, /* companion fclone skb (from fclone_cache) */
- SKB_FCLONE_FREE, /* this companion fclone skb is available */
};
enum {
@@ -818,7 +817,7 @@ static inline bool skb_fclone_busy(const struct sock *sk,
fclones = container_of(skb, struct sk_buff_fclones, skb1);
return skb->fclone == SKB_FCLONE_ORIG &&
- fclones->skb2.fclone == SKB_FCLONE_CLONE &&
+ atomic_read(&fclones->fclone_ref) > 1 &&
fclones->skb2.sk == sk;
}
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 92116dfe827c..7a338fb55cc4 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -265,7 +265,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
skb->fclone = SKB_FCLONE_ORIG;
atomic_set(&fclones->fclone_ref, 1);
- fclones->skb2.fclone = SKB_FCLONE_FREE;
+ fclones->skb2.fclone = SKB_FCLONE_CLONE;
fclones->skb2.pfmemalloc = pfmemalloc;
}
out:
@@ -541,26 +541,27 @@ static void kfree_skbmem(struct sk_buff *skb)
switch (skb->fclone) {
case SKB_FCLONE_UNAVAILABLE:
kmem_cache_free(skbuff_head_cache, skb);
- break;
+ return;
case SKB_FCLONE_ORIG:
fclones = container_of(skb, struct sk_buff_fclones, skb1);
- if (atomic_dec_and_test(&fclones->fclone_ref))
- kmem_cache_free(skbuff_fclone_cache, fclones);
- break;
-
- case SKB_FCLONE_CLONE:
- fclones = container_of(skb, struct sk_buff_fclones, skb2);
- /* The clone portion is available for
- * fast-cloning again.
+ /* We usually free the clone (TX completion) before original skb
+ * This test would have no chance to be true for the clone,
+ * while here, branch prediction will be good.
*/
- skb->fclone = SKB_FCLONE_FREE;
+ if (atomic_read(&fclones->fclone_ref) == 1)
+ goto fastpath;
+ break;
- if (atomic_dec_and_test(&fclones->fclone_ref))
- kmem_cache_free(skbuff_fclone_cache, fclones);
+ default: /* SKB_FCLONE_CLONE */
+ fclones = container_of(skb, struct sk_buff_fclones, skb2);
break;
}
+ if (!atomic_dec_and_test(&fclones->fclone_ref))
+ return;
+fastpath:
+ kmem_cache_free(skbuff_fclone_cache, fclones);
}
static void skb_release_head_state(struct sk_buff *skb)
@@ -872,15 +873,15 @@ struct sk_buff *skb_clone(struct sk_buff *skb, gfp_t gfp_mask)
struct sk_buff_fclones *fclones = container_of(skb,
struct sk_buff_fclones,
skb1);
- struct sk_buff *n = &fclones->skb2;
+ struct sk_buff *n;
if (skb_orphan_frags(skb, gfp_mask))
return NULL;
if (skb->fclone == SKB_FCLONE_ORIG &&
- n->fclone == SKB_FCLONE_FREE) {
- n->fclone = SKB_FCLONE_CLONE;
- atomic_inc(&fclones->fclone_ref);
+ atomic_read(&fclones->fclone_ref) == 1) {
+ n = &fclones->skb2;
+ atomic_set(&fclones->fclone_ref, 2);
} else {
if (skb_pfmemalloc(skb))
gfp_mask |= __GFP_MEMALLOC;
^ permalink raw reply related
* Re: [PATCH net-next 3/3] ip: Add support for IP_CHECKSUM cmsg
From: Eric Dumazet @ 2014-12-04 0:56 UTC (permalink / raw)
To: Tom Herbert, Michael Kerrisk; +Cc: davem, netdev
In-Reply-To: <1417653868-14922-4-git-send-email-therbert@google.com>
CC Michael Kerrisk <mtk.manpages@gmail.com> for man pages...
On Wed, 2014-12-03 at 16:44 -0800, Tom Herbert wrote:
> New cmsg type is IP_CHECKSUM under SOL_IP. Enabled by standard
> setsockopt.
>
> The value returned is the unfolded 32 bit checksum of the packet
> being received starting from the first byte returned in recvmsg
> through the end of the packet (truncation is disregarded).
>
> Modified UDP to postpull checksum beyond UDP header before returning
> checksum for UDP data to userspace.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> include/net/inet_sock.h | 1 +
> include/uapi/linux/in.h | 1 +
> net/ipv4/ip_sockglue.c | 34 +++++++++++++++++++++++++++++++++-
> net/ipv4/udp.c | 10 +++++++++-
> 4 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
> index 4091fab..2823fc0 100644
> --- a/include/net/inet_sock.h
> +++ b/include/net/inet_sock.h
> @@ -203,6 +203,7 @@ struct inet_sock {
> #define IP_CMSG_RETOPTS (1 << 4)
> #define IP_CMSG_PASSSEC (1 << 5)
> #define IP_CMSG_ORIGDSTADDR (1 << 6)
> +#define IP_CMSG_CHECKSUM (1 << 7)
>
> static inline struct inet_sock *inet_sk(const struct sock *sk)
> {
> diff --git a/include/uapi/linux/in.h b/include/uapi/linux/in.h
> index c33a65e..589ced0 100644
> --- a/include/uapi/linux/in.h
> +++ b/include/uapi/linux/in.h
> @@ -109,6 +109,7 @@ struct in_addr {
>
> #define IP_MINTTL 21
> #define IP_NODEFRAG 22
> +#define IP_CHECKSUM 23
>
> /* IP_MTU_DISCOVER values */
> #define IP_PMTUDISC_DONT 0 /* Never send DF frames */
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index d4406aa..054280f 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -96,6 +96,14 @@ static void ip_cmsg_recv_retopts(struct msghdr *msg, struct sk_buff *skb)
> put_cmsg(msg, SOL_IP, IP_RETOPTS, opt->optlen, opt->__data);
> }
>
> +static void ip_cmsg_recv_checksum(struct msghdr *msg, struct sk_buff *skb)
> +{
> + if (skb->ip_summed != CHECKSUM_COMPLETE)
> + return;
> +
> + put_cmsg(msg, SOL_IP, IP_CHECKSUM, sizeof(__wsum), &skb->csum);
> +}
> +
> static void ip_cmsg_recv_security(struct msghdr *msg, struct sk_buff *skb)
> {
> char *secdata;
> @@ -190,9 +198,16 @@ void ip_cmsg_recv(struct msghdr *msg, struct sk_buff *skb)
> return;
> }
>
> - if (flags & IP_CMSG_ORIGDSTADDR)
> + if (flags & IP_CMSG_ORIGDSTADDR) {
> ip_cmsg_recv_dstaddr(msg, skb);
>
> + flags &= ~IP_CMSG_ORIGDSTADDR;
> + if (!flags)
> + return;
> + }
> +
> + if (flags & IP_CMSG_CHECKSUM)
> + ip_cmsg_recv_checksum(msg, skb);
> }
> EXPORT_SYMBOL(ip_cmsg_recv);
>
> @@ -512,6 +527,7 @@ static int do_ip_setsockopt(struct sock *sk, int level,
> case IP_MULTICAST_ALL:
> case IP_MULTICAST_LOOP:
> case IP_RECVORIGDSTADDR:
> + case IP_CHECKSUM:
> if (optlen >= sizeof(int)) {
> if (get_user(val, (int __user *) optval))
> return -EFAULT;
> @@ -609,6 +625,19 @@ static int do_ip_setsockopt(struct sock *sk, int level,
> else
> inet->cmsg_flags &= ~IP_CMSG_ORIGDSTADDR;
> break;
> + case IP_CHECKSUM:
> + if (val) {
> + if (!(inet->cmsg_flags & IP_CMSG_CHECKSUM)) {
> + inet_inc_convert_csum(sk);
> + inet->cmsg_flags |= IP_CMSG_CHECKSUM;
> + }
> + } else {
> + if (inet->cmsg_flags & IP_CMSG_CHECKSUM) {
> + inet_dec_convert_csum(sk);
> + inet->cmsg_flags &= ~IP_CMSG_CHECKSUM;
> + }
> + }
> + break;
> case IP_TOS: /* This sets both TOS and Precedence */
> if (sk->sk_type == SOCK_STREAM) {
> val &= ~INET_ECN_MASK;
> @@ -1212,6 +1241,9 @@ static int do_ip_getsockopt(struct sock *sk, int level, int optname,
> case IP_RECVORIGDSTADDR:
> val = (inet->cmsg_flags & IP_CMSG_ORIGDSTADDR) != 0;
> break;
> + case IP_CHECKSUM:
> + val = (inet->cmsg_flags & IP_CMSG_CHECKSUM) != 0;
> + break;
> case IP_TOS:
> val = inet->tos;
> break;
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 221b53f..bba2e06 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1315,8 +1315,16 @@ try_again:
> memset(sin->sin_zero, 0, sizeof(sin->sin_zero));
> *addr_len = sizeof(*sin);
> }
> - if (inet->cmsg_flags)
> + if (inet->cmsg_flags) {
> + /* Pull checksum past UDP header in case we are providing
> + * checksum in cmsg.
> + */
> + if (inet->cmsg_flags & IP_CMSG_CHECKSUM)
> + skb_postpull_rcsum(skb, skb->data,
> + sizeof(struct udphdr));
> +
> ip_cmsg_recv(msg, skb);
> + }
>
> err = copied;
> if (flags & MSG_TRUNC)
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Jesse Gross @ 2014-12-04 0:54 UTC (permalink / raw)
To: Thomas Graf
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Michael S. Tsirkin,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Wang,
Du, Fan, fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <20141203230551.GC8822-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
On Wed, Dec 3, 2014 at 3:05 PM, Thomas Graf <tgraf@suug.ch> wrote:
> On 12/03/14 at 02:51pm, Jesse Gross wrote:
>> My proposal would be something like this:
>> * For L2, reduce the VM MTU to the lowest common denominator on the segment.
>> * For L3, use path MTU discovery or fragment inner packet (i.e.
>> normal routing behavior).
>> * As a last resort (such as if using an old version of virtio in the
>> guest), fragment the tunnel packet.
>
> That's what I had in mind as well although using a differentiator bit
> which indicates to the output path whether the packet is to be
> considered switched or routed and thus send ICMPs. The bit would be set
> per flow, thus allowing arbitary granularity of behaviour.
I don't think that we actually need a bit. I would expect that ICMP
generation to be coupled with routing (although this requires being
able to know what the ultimate MTU is at the time of routing the inner
packet). If that's the case, you just need to steer between L2 and L3
processing in the same way that you would today and ICMP would just
come in the right cases.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* [PATCH net-next 3/3] ip: Add support for IP_CHECKSUM cmsg
From: Tom Herbert @ 2014-12-04 0:44 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1417653868-14922-1-git-send-email-therbert@google.com>
New cmsg type is IP_CHECKSUM under SOL_IP. Enabled by standard
setsockopt.
The value returned is the unfolded 32 bit checksum of the packet
being received starting from the first byte returned in recvmsg
through the end of the packet (truncation is disregarded).
Modified UDP to postpull checksum beyond UDP header before returning
checksum for UDP data to userspace.
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/net/inet_sock.h | 1 +
include/uapi/linux/in.h | 1 +
net/ipv4/ip_sockglue.c | 34 +++++++++++++++++++++++++++++++++-
net/ipv4/udp.c | 10 +++++++++-
4 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
index 4091fab..2823fc0 100644
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -203,6 +203,7 @@ struct inet_sock {
#define IP_CMSG_RETOPTS (1 << 4)
#define IP_CMSG_PASSSEC (1 << 5)
#define IP_CMSG_ORIGDSTADDR (1 << 6)
+#define IP_CMSG_CHECKSUM (1 << 7)
static inline struct inet_sock *inet_sk(const struct sock *sk)
{
diff --git a/include/uapi/linux/in.h b/include/uapi/linux/in.h
index c33a65e..589ced0 100644
--- a/include/uapi/linux/in.h
+++ b/include/uapi/linux/in.h
@@ -109,6 +109,7 @@ struct in_addr {
#define IP_MINTTL 21
#define IP_NODEFRAG 22
+#define IP_CHECKSUM 23
/* IP_MTU_DISCOVER values */
#define IP_PMTUDISC_DONT 0 /* Never send DF frames */
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index d4406aa..054280f 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -96,6 +96,14 @@ static void ip_cmsg_recv_retopts(struct msghdr *msg, struct sk_buff *skb)
put_cmsg(msg, SOL_IP, IP_RETOPTS, opt->optlen, opt->__data);
}
+static void ip_cmsg_recv_checksum(struct msghdr *msg, struct sk_buff *skb)
+{
+ if (skb->ip_summed != CHECKSUM_COMPLETE)
+ return;
+
+ put_cmsg(msg, SOL_IP, IP_CHECKSUM, sizeof(__wsum), &skb->csum);
+}
+
static void ip_cmsg_recv_security(struct msghdr *msg, struct sk_buff *skb)
{
char *secdata;
@@ -190,9 +198,16 @@ void ip_cmsg_recv(struct msghdr *msg, struct sk_buff *skb)
return;
}
- if (flags & IP_CMSG_ORIGDSTADDR)
+ if (flags & IP_CMSG_ORIGDSTADDR) {
ip_cmsg_recv_dstaddr(msg, skb);
+ flags &= ~IP_CMSG_ORIGDSTADDR;
+ if (!flags)
+ return;
+ }
+
+ if (flags & IP_CMSG_CHECKSUM)
+ ip_cmsg_recv_checksum(msg, skb);
}
EXPORT_SYMBOL(ip_cmsg_recv);
@@ -512,6 +527,7 @@ static int do_ip_setsockopt(struct sock *sk, int level,
case IP_MULTICAST_ALL:
case IP_MULTICAST_LOOP:
case IP_RECVORIGDSTADDR:
+ case IP_CHECKSUM:
if (optlen >= sizeof(int)) {
if (get_user(val, (int __user *) optval))
return -EFAULT;
@@ -609,6 +625,19 @@ static int do_ip_setsockopt(struct sock *sk, int level,
else
inet->cmsg_flags &= ~IP_CMSG_ORIGDSTADDR;
break;
+ case IP_CHECKSUM:
+ if (val) {
+ if (!(inet->cmsg_flags & IP_CMSG_CHECKSUM)) {
+ inet_inc_convert_csum(sk);
+ inet->cmsg_flags |= IP_CMSG_CHECKSUM;
+ }
+ } else {
+ if (inet->cmsg_flags & IP_CMSG_CHECKSUM) {
+ inet_dec_convert_csum(sk);
+ inet->cmsg_flags &= ~IP_CMSG_CHECKSUM;
+ }
+ }
+ break;
case IP_TOS: /* This sets both TOS and Precedence */
if (sk->sk_type == SOCK_STREAM) {
val &= ~INET_ECN_MASK;
@@ -1212,6 +1241,9 @@ static int do_ip_getsockopt(struct sock *sk, int level, int optname,
case IP_RECVORIGDSTADDR:
val = (inet->cmsg_flags & IP_CMSG_ORIGDSTADDR) != 0;
break;
+ case IP_CHECKSUM:
+ val = (inet->cmsg_flags & IP_CMSG_CHECKSUM) != 0;
+ break;
case IP_TOS:
val = inet->tos;
break;
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 221b53f..bba2e06 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1315,8 +1315,16 @@ try_again:
memset(sin->sin_zero, 0, sizeof(sin->sin_zero));
*addr_len = sizeof(*sin);
}
- if (inet->cmsg_flags)
+ if (inet->cmsg_flags) {
+ /* Pull checksum past UDP header in case we are providing
+ * checksum in cmsg.
+ */
+ if (inet->cmsg_flags & IP_CMSG_CHECKSUM)
+ skb_postpull_rcsum(skb, skb->data,
+ sizeof(struct udphdr));
+
ip_cmsg_recv(msg, skb);
+ }
err = copied;
if (flags & MSG_TRUNC)
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next 1/3] ip: Move checksum convert defines to inet
From: Tom Herbert @ 2014-12-04 0:44 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1417653868-14922-1-git-send-email-therbert@google.com>
Move convert_csum from udp_sock to inet_sock. This allows the
possibility that we can use convert checksum for different types
of sockets and also allows convert checksum to be enabled from
inet layer (what we'll want to do when enabling IP_CHECKSUM cmsg).
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/udp.h | 16 +---------------
include/net/inet_sock.h | 17 +++++++++++++++++
net/ipv4/fou.c | 2 +-
net/ipv4/udp.c | 2 +-
net/ipv4/udp_tunnel.c | 2 +-
net/ipv6/udp.c | 2 +-
6 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/include/linux/udp.h b/include/linux/udp.h
index ee32775..247cfdc 100644
--- a/include/linux/udp.h
+++ b/include/linux/udp.h
@@ -49,11 +49,7 @@ struct udp_sock {
unsigned int corkflag; /* Cork is required */
__u8 encap_type; /* Is this an Encapsulation socket? */
unsigned char no_check6_tx:1,/* Send zero UDP6 checksums on TX? */
- no_check6_rx:1,/* Allow zero UDP6 checksums on RX? */
- convert_csum:1;/* On receive, convert checksum
- * unnecessary to checksum complete
- * if possible.
- */
+ no_check6_rx:1;/* Allow zero UDP6 checksums on RX? */
/*
* Following member retains the information to create a UDP header
* when the socket is uncorked.
@@ -102,16 +98,6 @@ static inline bool udp_get_no_check6_rx(struct sock *sk)
return udp_sk(sk)->no_check6_rx;
}
-static inline void udp_set_convert_csum(struct sock *sk, bool val)
-{
- udp_sk(sk)->convert_csum = val;
-}
-
-static inline bool udp_get_convert_csum(struct sock *sk)
-{
- return udp_sk(sk)->convert_csum;
-}
-
#define udp_portaddr_for_each_entry(__sk, node, list) \
hlist_nulls_for_each_entry(__sk, node, list, __sk_common.skc_portaddr_node)
diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
index a829b77..360b110 100644
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -184,6 +184,7 @@ struct inet_sock {
mc_all:1,
nodefrag:1;
__u8 rcv_tos;
+ __u8 convert_csum;
int uc_index;
int mc_index;
__be32 mc_addr;
@@ -250,4 +251,20 @@ static inline __u8 inet_sk_flowi_flags(const struct sock *sk)
return flags;
}
+static inline void inet_inc_convert_csum(struct sock *sk)
+{
+ inet_sk(sk)->convert_csum++;
+}
+
+static inline void inet_dec_convert_csum(struct sock *sk)
+{
+ if (inet_sk(sk)->convert_csum > 0)
+ inet_sk(sk)->convert_csum--;
+}
+
+static inline bool inet_get_convert_csum(struct sock *sk)
+{
+ return !!inet_sk(sk)->convert_csum;
+}
+
#endif /* _INET_SOCK_H */
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index b986298..2197c36 100644
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -490,7 +490,7 @@ static int fou_create(struct net *net, struct fou_cfg *cfg,
sk->sk_user_data = fou;
fou->sock = sock;
- udp_set_convert_csum(sk, true);
+ inet_inc_convert_csum(sk);
sk->sk_allocation = GFP_ATOMIC;
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index b2d6068..221b53f 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1793,7 +1793,7 @@ int __udp4_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
if (sk != NULL) {
int ret;
- if (udp_sk(sk)->convert_csum && uh->check && !IS_UDPLITE(sk))
+ if (inet_get_convert_csum(sk) && uh->check && !IS_UDPLITE(sk))
skb_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
inet_compute_pseudo);
diff --git a/net/ipv4/udp_tunnel.c b/net/ipv4/udp_tunnel.c
index 1671263..9996e63 100644
--- a/net/ipv4/udp_tunnel.c
+++ b/net/ipv4/udp_tunnel.c
@@ -63,7 +63,7 @@ void setup_udp_tunnel_sock(struct net *net, struct socket *sock,
inet_sk(sk)->mc_loop = 0;
/* Enable CHECKSUM_UNNECESSARY to CHECKSUM_COMPLETE conversion */
- udp_set_convert_csum(sk, true);
+ inet_inc_convert_csum(sk);
rcu_assign_sk_user_data(sk, cfg->sk_user_data);
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 7cfb5d7..5d9900c 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -896,7 +896,7 @@ int __udp6_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
goto csum_error;
}
- if (udp_sk(sk)->convert_csum && uh->check && !IS_UDPLITE(sk))
+ if (inet_get_convert_csum(sk) && uh->check && !IS_UDPLITE(sk))
skb_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
ip6_compute_pseudo);
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next 0/3] ip: Support checksum returned in csmg
From: Tom Herbert @ 2014-12-04 0:44 UTC (permalink / raw)
To: davem, netdev
This patch set allows the packet checksum for a datagram socket
to be returned in csum data in recvmsg. This allows userspace
to implement its own checksum over the data, for instance if an
IP tunnel was be implemented in user space, the inner checksum
could be validated.
Changes in this patch set:
- Move checksum conversion to inet_sock from udp_sock. This
generalizes checksum conversion for use with other protocols.
- Move IP cmsg constants to a header file and make processing
of the flags more efficient in ip_cmsg_recv.
- Return checksum value in cmsg. This is specifically the unfolded
32 bit checksum of the full packet starting from the first byte
returned in recvmsg.
Tested: Wrote a little server to get checksums in cmsg for UDP and
verfied correct checksum is returned.
Tom Herbert (3):
ip: Move checksum convert defines to inet
ip: IP cmsg cleanup
ip: Add support for IP_CHECKSUM cmsg
include/linux/udp.h | 16 +--------
include/net/inet_sock.h | 27 ++++++++++++++
include/uapi/linux/in.h | 1 +
net/ipv4/fou.c | 2 +-
net/ipv4/ip_sockglue.c | 96 +++++++++++++++++++++++++++++++++++--------------
net/ipv4/udp.c | 12 +++++--
net/ipv4/udp_tunnel.c | 2 +-
net/ipv6/udp.c | 2 +-
8 files changed, 111 insertions(+), 47 deletions(-)
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply
* Re: [patch net-next v4 8/9] net: move vlan pop/push functions into common code
From: Pravin Shelar @ 2014-12-04 0:33 UTC (permalink / raw)
To: Jiri Benc
Cc: Jiri Pirko, netdev, David Miller, Jamal Hadi Salim, Tom Herbert,
Eric Dumazet, Willem de Bruijn, Daniel Borkmann, mst, fw,
Paul.Durrant, Thomas Graf, Cong Wang
In-Reply-To: <20141121202933.2970b7ea@griffin>
On Fri, Nov 21, 2014 at 11:29 AM, Jiri Benc <jbenc@redhat.com> wrote:
> On Fri, 21 Nov 2014 10:41:27 -0800, Pravin Shelar wrote:
>> There is bug in the openvswitch code where vlan-pop does mac-length
>> reset rather than subtracting VLAN_HLEN from mac-len. MPLS code
>> depends on this. Now this patch moves the bug to common code. I am
>> fine with this patch and I can send fix to change code vlan-pop code
>> to adjust mac_len later on.
>> But I am worried about the comment made by Jiri Benc on earlier
>> version of this patch where is mentioned that subtracting VLAN_HLEN
>> can break common case for vlan-pop. In that case we can not change
>> this common function. Jiri Benc, Can you point me to the code, so the
>> we can work on solution to fix this issue.
>
> In such case, a skb that enters the __pop_vlan_tci function looks like
> this:
>
> +--------+--------+-------------+-----+---------+-------
> | dstmac | srcmac | ETH_P_8021Q | tci | ETH_P_x | data
> +--------+--------+-------------+-----+---------+-------
> ^ ^
> mac_header network_header
>
> skb->protocol = ETH_P_8021Q
> skb->mac_len = 14
>
> After the function finishes, it's supposed to look like this:
>
> +--------+--------+---------+-------
> | dstmac | srcmac | ETH_P_x | data
> +--------+--------+---------+-------
> ^ ^
> mac_header network_header
>
> skb->protocol = ETH_P_x
> skb->mac_len = 14
>
> Blindly decrementing mac_len wouldn't work here, you'd end up with
> mac_len = 10. You'd either need to ensure this case doesn't happen (it
> does with openvswitch currently) or detect this case.
>
OVS correctly sets mac header length in case of vlan header. Can you
give me OVS test case to reproduce this issue?
^ permalink raw reply
* Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request
From: Vadim Kochan @ 2014-12-04 0:00 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20141203232819.GA12656@angus-think.lan>
Ofcourse I think it is possible to add checking if protocol ==
NETLINK_INET_DIAG protocol
and dont print the error message in lib/netlink.c if errno == ENOENT,
but I am not sure if you will like such approach ...
On Thu, Dec 4, 2014 at 1:28 AM, <vadim4j@gmail.com> wrote:
> On Wed, Dec 03, 2014 at 03:07:48PM -0800, Stephen Hemminger wrote:
>> On Thu, 4 Dec 2014 00:15:54 +0200
>> Vadim Kochan <vadim4j@gmail.com> wrote:
>>
>> > I established some simple OpenVPN connection (at least by the logs and
>> > ss I see that peer is connected), but
>> > I dont get any errors with ss.
>> >
>> > So can you please provide some more info how did you tested this patch
>> > ? I am surprised that this is caused only
>> > by these changes ...
>> >
>> > On Wed, Dec 3, 2014 at 7:45 PM, <vadim4j@gmail.com> wrote:
>> > > On Wed, Dec 03, 2014 at 09:51:23AM -0800, Stephen Hemminger wrote:
>> > >> On Wed, 3 Dec 2014 19:20:10 +0200
>> > >> vadim4j@gmail.com wrote:
>> > >>
>> > >> > On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
>> > >> > > On Tue, 2 Dec 2014 16:53:04 +0200
>> > >> > > Vadim Kochan <vadim4j@gmail.com> wrote:
>> > >> > >
>> > >> > > > Replaced handling netlink messages by rtnl_dump_filter
>> > >> > > > from lib/libnetlink.c, also:
>> > >> > > >
>> > >> > > > - removed unused dump_fp arg;
>> > >> > > > - added MAGIC_SEQ #define for 123456 seq id
>> > >> > > >
>> > >> > > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
>> > >> > >
>> > >> > > This doesn't work correctly.
>> > >> > >
>> > >> > > Simple test
>> > >> > > $ misc/ss >/dev/null
>> > >> > > RTNETLINK answers: No such file or directory
>> > >> > > RTNETLINK answers: No such file or directory
>> > >> > > RTNETLINK answers: No such file or directory
>> > >> >
>> > >> > Just tried, I did not get such errors.
>> > >>
>> > >> I have OpenVPN running.
>> > >
>> > > Hm, it is reproduced only with this patch ?
>> > > If so I will try to setup OpenVPN ... can't imagine how it can be
>> > > related ...
>>
>> I am running on 3.17.4 kernel if that helps.
>
> OK, thank you!
>
> I see a reason why it was caused by this patch. So the difference is in
> the way how the libnetlink/rtnl_* and original ss.c handles the
> NLMSG_ERROR, ss.c netlink handler checks errno ENOENT (No such file or directory)
> and silently closes file end returns -1, but rtnl_* prints the error message.
>
> Meanwhile I dont know the real reason why ENOENT error is happaned, may
> be it is OK in context of diagnostic messages. But I grepped over the
> commits and found that this ENOENT checking was added by Eric in:
>
> commit a3fd8e58c1787af186f5c4b234ff974544f840b6
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon Jan 30 17:05:45 2012 +0100
>
> ss: should support CONFIG_INET_UDP_DIAG=n kernels
>
> ss -x currently fails if CONFIG_INET_UDP_DIAG=n or old kernels
>
> Also close file descriptors while we are at it.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Pavel Emelyanov <xemul@parallels.com>
^ permalink raw reply
* Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request
From: vadim4j @ 2014-12-03 23:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20141203150748.001d481e@urahara>
On Wed, Dec 03, 2014 at 03:07:48PM -0800, Stephen Hemminger wrote:
> On Thu, 4 Dec 2014 00:15:54 +0200
> Vadim Kochan <vadim4j@gmail.com> wrote:
>
> > I established some simple OpenVPN connection (at least by the logs and
> > ss I see that peer is connected), but
> > I dont get any errors with ss.
> >
> > So can you please provide some more info how did you tested this patch
> > ? I am surprised that this is caused only
> > by these changes ...
> >
> > On Wed, Dec 3, 2014 at 7:45 PM, <vadim4j@gmail.com> wrote:
> > > On Wed, Dec 03, 2014 at 09:51:23AM -0800, Stephen Hemminger wrote:
> > >> On Wed, 3 Dec 2014 19:20:10 +0200
> > >> vadim4j@gmail.com wrote:
> > >>
> > >> > On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
> > >> > > On Tue, 2 Dec 2014 16:53:04 +0200
> > >> > > Vadim Kochan <vadim4j@gmail.com> wrote:
> > >> > >
> > >> > > > Replaced handling netlink messages by rtnl_dump_filter
> > >> > > > from lib/libnetlink.c, also:
> > >> > > >
> > >> > > > - removed unused dump_fp arg;
> > >> > > > - added MAGIC_SEQ #define for 123456 seq id
> > >> > > >
> > >> > > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> > >> > >
> > >> > > This doesn't work correctly.
> > >> > >
> > >> > > Simple test
> > >> > > $ misc/ss >/dev/null
> > >> > > RTNETLINK answers: No such file or directory
> > >> > > RTNETLINK answers: No such file or directory
> > >> > > RTNETLINK answers: No such file or directory
> > >> >
> > >> > Just tried, I did not get such errors.
> > >>
> > >> I have OpenVPN running.
> > >
> > > Hm, it is reproduced only with this patch ?
> > > If so I will try to setup OpenVPN ... can't imagine how it can be
> > > related ...
>
> I am running on 3.17.4 kernel if that helps.
OK, thank you!
I see a reason why it was caused by this patch. So the difference is in
the way how the libnetlink/rtnl_* and original ss.c handles the
NLMSG_ERROR, ss.c netlink handler checks errno ENOENT (No such file or directory)
and silently closes file end returns -1, but rtnl_* prints the error message.
Meanwhile I dont know the real reason why ENOENT error is happaned, may
be it is OK in context of diagnostic messages. But I grepped over the
commits and found that this ENOENT checking was added by Eric in:
commit a3fd8e58c1787af186f5c4b234ff974544f840b6
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon Jan 30 17:05:45 2012 +0100
ss: should support CONFIG_INET_UDP_DIAG=n kernels
ss -x currently fails if CONFIG_INET_UDP_DIAG=n or old kernels
Also close file descriptors while we are at it.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Pavel Emelyanov <xemul@parallels.com>
^ permalink raw reply
* Re: [PATCH net] Update old iproute2 and Xen Remus links
From: Stephen Hemminger @ 2014-12-03 23:34 UTC (permalink / raw)
To: Andrew Shewmaker; +Cc: linux-doc, linux-kernel, netdev, corbet, jhs, davem
In-Reply-To: <1417644451-7305-1-git-send-email-agshew@gmail.com>
On Wed, 3 Dec 2014 14:07:31 -0800
Andrew Shewmaker <agshew@gmail.com> wrote:
> Signed-off-by: Andrew Shewmaker <agshew@gmail.com>
> ---
> Documentation/Changes | 2 +-
> net/sched/Kconfig | 7 ++++---
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/Changes b/Documentation/Changes
> index 1de131b..74bdda9 100644
> --- a/Documentation/Changes
> +++ b/Documentation/Changes
> @@ -383,7 +383,7 @@ o <http://www.iptables.org/downloads.html>
>
> Ip-route2
> ---------
> -o <ftp://ftp.tux.org/pub/net/ip-routing/iproute2-2.2.4-now-ss991023.tar.gz>
> +o <https://www.kernel.org/pub/linux/utils/net/iproute2/>
>
> OProfile
> --------
> diff --git a/net/sched/Kconfig b/net/sched/Kconfig
> index a1a8e29..d17053d 100644
> --- a/net/sched/Kconfig
> +++ b/net/sched/Kconfig
> @@ -22,8 +22,9 @@ menuconfig NET_SCHED
> This code is considered to be experimental.
>
> To administer these schedulers, you'll need the user-level utilities
> - from the package iproute2+tc at <ftp://ftp.tux.org/pub/net/ip-routing/>.
> - That package also contains some documentation; for more, check out
> + from the package iproute2+tc at
> + <https://www.kernel.org/pub/linux/utils/net/iproute2/>. That package
> + also contains some documentation; for more, check out
> <http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2>.
>
> This Quality of Service (QoS) support will enable you to use
> @@ -336,7 +337,7 @@ config NET_SCH_PLUG
> of virtual machines by allowing the generated network output to be rolled
> back if needed.
>
> - For more information, please refer to http://wiki.xensource.com/xenwiki/Remus
> + For more information, please refer to <http://wiki.xenproject.org/wiki/Remus>
>
> Say Y here if you are using this kernel for Xen dom0 and
> want to protect Xen guests with Remus.
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply
* Re: [patch net-next 3/6] net_sched: cls_bpf: remove faulty use of list_for_each_entry_rcu
From: Daniel Borkmann @ 2014-12-03 23:15 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: Jiri Pirko, netdev, davem
In-Reply-To: <547F7D6D.3000709@mojatatu.com>
On 12/03/2014 10:15 PM, Jamal Hadi Salim wrote:
...
> I am not an rcu officionado. So if the control path is doing a non-rcu
> get + rcu-del/change (update) then as long as the fastpath is (read)
> rcu locking we are fine and nothing will actually happen until the
> fastpath releases and rcu grace period ends, correct?
So if the control path does a list_del_rcu() and call_rcu() under
lock and iterates over list_for_each_entry{,safe}() [which we do
in cls_bpf_delete()], while the fast path [cls_bpf_classify()] uses
a rcu_read_{un,}lock() with *_rcu list iterator, that's fine then,
as it's still guaranteed to be deleted after the grace period. So
Jiri's change looks good to me.
Acked-by: Daniel Borkmann <dborkman@redhat.com>
^ permalink raw reply
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