* Re: [PATCH v2 1/1] tcp: fixing TLP's FIN recovery
From: David Miller @ 2014-10-07 20:17 UTC (permalink / raw)
To: joshhunt00
Cc: per.hurtig, eric.dumazet, panweiping3, nanditad, netdev,
anna.brunstrom, mohammad.rajiullah, ncardwell, sergei.shtylyov
In-Reply-To: <CAKA=qzZ+L67Z4O7DY0hR_N=5VFSZ2_Dn0to+8WLqnpfgQg+00Q@mail.gmail.com>
From: Josh Hunt <joshhunt00@gmail.com>
Date: Tue, 7 Oct 2014 10:03:29 -0500
> On Thu, Jun 12, 2014 at 1:06 PM, David Miller <davem@davemloft.net> wrote:
>> From: Per Hurtig <per.hurtig@kau.se>
>> Date: Thu, 12 Jun 2014 17:08:32 +0200
>>
>>> Fix to a problem observed when losing a FIN segment that does not
>>> contain data. In such situations, TLP is unable to recover from
>>> *any* tail loss and instead adds at least PTO ms to the
>>> retransmission process, i.e., RTO = RTO + PTO.
>>>
>>> Signed-off-by: Per Hurtig <per.hurtig@kau.se>
>>
>> Applied, thanks.
>
> Can we queue this up for stable? 2cd0d743b05e87 (tcp: fix
> tcp_match_skb_to_sack() for unaligned SACK at end of an skb) is
> already in stable and based on the changelog was put in place to fix a
> case that this patch introduced:
>
> "This was visible now because the recently simplified TLP logic in
> bef1909ee3ed1c ("tcp: fixing TLP's FIN recovery") could find that 0-byte
> skb at the end of the write queue, and now that we do not check that
> skb's length we could send it as a TLP probe."
>
> However, the patch to fix TLP's FIN recovery is not in -stable.
Queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: David Miller @ 2014-10-07 20:18 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, netdev
In-Reply-To: <1412712996-4672-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Tue, 7 Oct 2014 22:16:36 +0200
> static values are automatically initialized to NULL
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Isn't there some implementation room given to compilers
as to the representation of true and false?
^ permalink raw reply
* [PATCH 1/1 net-next] net: rfkill: kernel-doc warning fixes
From: Fabian Frederick @ 2014-10-07 20:20 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, John W. Linville, Johannes Berg,
David S. Miller, linux-wireless, netdev
s/state/blocked
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/rfkill/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index b3b16c0..fa7cd79 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -329,7 +329,7 @@ static atomic_t rfkill_input_disabled = ATOMIC_INIT(0);
/**
* __rfkill_switch_all - Toggle state of all switches of given type
* @type: type of interfaces to be affected
- * @state: the new state
+ * @blocked: the new state
*
* This function sets the state of all switches of given type,
* unless a specific switch is claimed by userspace (in which case,
@@ -353,7 +353,7 @@ static void __rfkill_switch_all(const enum rfkill_type type, bool blocked)
/**
* rfkill_switch_all - Toggle state of all switches of given type
* @type: type of interfaces to be affected
- * @state: the new state
+ * @blocked: the new state
*
* Acquires rfkill_global_mutex and calls __rfkill_switch_all(@type, @state).
* Please refer to __rfkill_switch_all() for details.
--
1.9.3
^ permalink raw reply related
* Re: r8168 is needed to enter P-state: Package State 6 (pc6)onHaswell hardware
From: Francois Romieu @ 2014-10-07 20:16 UTC (permalink / raw)
To: Ceriel Jacobs; +Cc: Hayes Wang, nic_swsd, netdev@vger.kernel.org
In-Reply-To: <5433C33B.2060700@crashplan.pro>
Ceriel Jacobs <linux-ide@crashplan.pro> :
> Francois Romieu schreef op 07-10-14 om 00:13:
[...]
> >Realtek's r8168 driver defaults to CONFIG_ASPM=1
>
> # modinfo r8168 suggests the opposite (ASPM is disabled by default):
> version: 8.039.00-NAPI
> parm: aspm:Enable ASPM. (int)
$ grep CONFIG_ASPM src/Makefile
CONFIG_ASPM = y
$ less src/r8168_n.c
[...]
#ifdef CONFIG_ASPM
static int aspm = 1;
#else
static int aspm = 0;
#endif
[...]
> Francois, what do you mean with "current kernel", the latest Ubuntu mainline
> kernel or something different?
Sorry. I meant current mainline as seen from git but anything close like
v3.15.x, v3.16.y or v3.17.k should be fine (patch applies).
--
Ueimor
^ permalink raw reply
* Re: sunvnet and ->xmit_more
From: David L Stevens @ 2014-10-07 20:22 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Raghuram.Kothakota, sowmini.varadhan
In-Reply-To: <20141007.151849.84417269004453869.davem@davemloft.net>
On 10/07/2014 03:18 PM, David Miller wrote:
>
> David and others working on sunvnet, I just wanted to point out that
> in the net-next tree there is a new facility that can improve
> performance quite a bit in sunvnet.
Yes, that looks interesting. Thanks!
+-DLS
^ permalink raw reply
* Re: r8168 is needed to enter P-state: Package State 6(pc6)onHaswellhardware
From: Francois Romieu @ 2014-10-07 20:17 UTC (permalink / raw)
To: Hayes Wang; +Cc: Ceriel Jacobs, nic_swsd, netdev@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB2526B88@RTITMBSV03.realtek.com.tw>
Hayes Wang <hayeswang@realtek.com> :
[...]
> When enabling the ASPM, it would influence the thrpughput. It is hard to
> choose performance or power saving. Therefore, we reserve the config
> to let the user determines it.
Mmmm...
How do Realtek's devices behave if Config{2, 3} + MISC registers are
configured for ASPM whereas PCI config space registers aren't ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: Hannes Frederic Sowa @ 2014-10-07 20:26 UTC (permalink / raw)
To: David Miller; +Cc: fabf, linux-kernel, netdev
In-Reply-To: <20141007.161832.453892039501955243.davem@davemloft.net>
On Di, 2014-10-07 at 16:18 -0400, David Miller wrote:
> From: Fabian Frederick <fabf@skynet.be>
> Date: Tue, 7 Oct 2014 22:16:36 +0200
>
> > static values are automatically initialized to NULL
> >
> > Signed-off-by: Fabian Frederick <fabf@skynet.be>
>
> Isn't there some implementation room given to compilers
> as to the representation of true and false?
No, the standard requests implementations to implement false as 0 and
true as 1.
In case of assignments e.g. INT_MAX to _Bool (=bool) it will implicitly
converted to 1, so one can omit the often used !! with booleans.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next] icmp6: Add new icmpv6 type for RPL control message
From: Hannes Frederic Sowa @ 2014-10-07 20:26 UTC (permalink / raw)
To: David Miller; +Cc: simon.vincent, netdev
In-Reply-To: <20141007.155545.116517484203308074.davem@davemloft.net>
On Di, 2014-10-07 at 15:55 -0400, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Tue, 07 Oct 2014 01:53:46 +0200
>
> > Might be possible, but I would favor to get rid of the printk or move
> > the test for informational icmp notifications up.
> > Some of the type < 128 icmp (non-informal) packets we also report to
> > user space, so we cannot just add them to a blacklist.
>
> So basically:
>
> diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
> index 141e1f3..97ae700 100644
> --- a/net/ipv6/icmp.c
> +++ b/net/ipv6/icmp.c
> @@ -777,12 +777,12 @@ static int icmpv6_rcv(struct sk_buff *skb)
> break;
>
> default:
> - LIMIT_NETDEBUG(KERN_DEBUG "icmpv6: msg of unknown type\n");
> -
> /* informational */
> if (type & ICMPV6_INFOMSG_MASK)
> break;
>
> + LIMIT_NETDEBUG(KERN_DEBUG "icmpv6: msg of unknown type\n");
> +
> /*
> * error of unknown type.
> * must pass to upper level
Yep, can you take care of this?
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks! :)
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: Alexei Starovoitov @ 2014-10-07 20:28 UTC (permalink / raw)
To: David Miller
Cc: Tom Herbert, Jesse Gross, gerlitz.or@gmail.com, Alexander Duyck,
John Fastabend, Jeff Kirsher, netdev@vger.kernel.org, Thomas Graf,
Pravin Shelar, Andy Zhou
In-Reply-To: <20141007.144752.657165589422333613.davem@davemloft.net>
On Tue, Oct 7, 2014 at 11:47 AM, David Miller <davem@davemloft.net> wrote:
>
> I am totally against boolean "yes/no" protocol specific checksum
> validation by HW.
>
> It's not faster. You have to look at the pseudo-header and bring it into
> the CPU cache _anyways_, so negating it and 2's complementing it into
> the CHECKSUM_COMPLETE value for validation is free.
>
> There is no performance advantage whatsoever to use another checksumming
> scheme.
ok, forget faster/slower argument for a second.
Why is it a bad thing to have HW verifying checksums?
Tom's argument of difficult bugs in firmware is valid, but there can be bugs
in hw too and in kernel stack...
Also NICs do verify csum already. What are we saying here? Stop doing it?
I can trust only kernel stack to verify csum?
btw, just remembered why COMPLETE is slow in the datacenter...
virtio doesn't have support for it. Packets going into tap without
VIRTIO_NET_HDR_F_DATA_VALID, so guests have to do whole
packet csum.
^ permalink raw reply
* [PATCH net-next] i40e: skb->xmit_more support
From: Eric Dumazet @ 2014-10-07 20:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Daniel Borkmann, Jeff Kirsher
From: Eric Dumazet <edumazet@google.com>
Support skb->xmit_more in i40e is straightforward : we need to move
around i40e_maybe_stop_tx() call to correctly test netif_xmit_stopped()
before taking the decision to not kick the NIC.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 90 +++++++++---------
1 file changed, 46 insertions(+), 44 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 267992b3de8a..3195d82e4942 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2053,6 +2053,47 @@ static void i40e_create_tx_ctx(struct i40e_ring *tx_ring,
}
/**
+ * __i40e_maybe_stop_tx - 2nd level check for tx stop conditions
+ * @tx_ring: the ring to be checked
+ * @size: the size buffer we want to assure is available
+ *
+ * Returns -EBUSY if a stop is needed, else 0
+ **/
+static inline int __i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
+{
+ netif_stop_subqueue(tx_ring->netdev, tx_ring->queue_index);
+ /* Memory barrier before checking head and tail */
+ smp_mb();
+
+ /* Check again in a case another CPU has just made room available. */
+ if (likely(I40E_DESC_UNUSED(tx_ring) < size))
+ return -EBUSY;
+
+ /* A reprieve! - use start_queue because it doesn't call schedule */
+ netif_start_subqueue(tx_ring->netdev, tx_ring->queue_index);
+ ++tx_ring->tx_stats.restart_queue;
+ return 0;
+}
+
+/**
+ * i40e_maybe_stop_tx - 1st level check for tx stop conditions
+ * @tx_ring: the ring to be checked
+ * @size: the size buffer we want to assure is available
+ *
+ * Returns 0 if stop is not needed
+ **/
+#ifdef I40E_FCOE
+int i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
+#else
+static int i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
+#endif
+{
+ if (likely(I40E_DESC_UNUSED(tx_ring) >= size))
+ return 0;
+ return __i40e_maybe_stop_tx(tx_ring, size);
+}
+
+/**
* i40e_tx_map - Build the Tx descriptor
* @tx_ring: ring to send buffer on
* @skb: send buffer
@@ -2195,8 +2236,12 @@ static void i40e_tx_map(struct i40e_ring *tx_ring, struct sk_buff *skb,
tx_ring->next_to_use = i;
+ i40e_maybe_stop_tx(tx_ring, DESC_NEEDED);
/* notify HW of packet */
- writel(i, tx_ring->tail);
+ if (!skb->xmit_more ||
+ netif_xmit_stopped(netdev_get_tx_queue(tx_ring->netdev,
+ tx_ring->queue_index)))
+ writel(i, tx_ring->tail);
return;
@@ -2218,47 +2263,6 @@ dma_error:
}
/**
- * __i40e_maybe_stop_tx - 2nd level check for tx stop conditions
- * @tx_ring: the ring to be checked
- * @size: the size buffer we want to assure is available
- *
- * Returns -EBUSY if a stop is needed, else 0
- **/
-static inline int __i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
-{
- netif_stop_subqueue(tx_ring->netdev, tx_ring->queue_index);
- /* Memory barrier before checking head and tail */
- smp_mb();
-
- /* Check again in a case another CPU has just made room available. */
- if (likely(I40E_DESC_UNUSED(tx_ring) < size))
- return -EBUSY;
-
- /* A reprieve! - use start_queue because it doesn't call schedule */
- netif_start_subqueue(tx_ring->netdev, tx_ring->queue_index);
- ++tx_ring->tx_stats.restart_queue;
- return 0;
-}
-
-/**
- * i40e_maybe_stop_tx - 1st level check for tx stop conditions
- * @tx_ring: the ring to be checked
- * @size: the size buffer we want to assure is available
- *
- * Returns 0 if stop is not needed
- **/
-#ifdef I40E_FCOE
-int i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
-#else
-static int i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
-#endif
-{
- if (likely(I40E_DESC_UNUSED(tx_ring) >= size))
- return 0;
- return __i40e_maybe_stop_tx(tx_ring, size);
-}
-
-/**
* i40e_xmit_descriptor_count - calculate number of tx descriptors needed
* @skb: send buffer
* @tx_ring: ring to send buffer on
@@ -2372,8 +2376,6 @@ static netdev_tx_t i40e_xmit_frame_ring(struct sk_buff *skb,
i40e_tx_map(tx_ring, skb, first, tx_flags, hdr_len,
td_cmd, td_offset);
- i40e_maybe_stop_tx(tx_ring, DESC_NEEDED);
-
return NETDEV_TX_OK;
out_drop:
^ permalink raw reply related
* [PATCH 1/1 net-next] netlabel: kernel-doc warning fix
From: Fabian Frederick @ 2014-10-07 20:31 UTC (permalink / raw)
To: linux-kernel; +Cc: Fabian Frederick, Paul Moore, David S. Miller, netdev
no secid argument in netlbl_cfg_unlbl_static_del
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/netlabel/netlabel_kapi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index 0b4692d..a845cd4 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -246,7 +246,6 @@ int netlbl_cfg_unlbl_static_add(struct net *net,
* @addr: IP address in network byte order (struct in[6]_addr)
* @mask: address mask in network byte order (struct in[6]_addr)
* @family: address family
- * @secid: LSM secid value for the entry
* @audit_info: NetLabel audit information
*
* Description:
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] net: Add ndo_gso_check
From: David Miller @ 2014-10-07 20:32 UTC (permalink / raw)
To: alexei.starovoitov
Cc: therbert, jesse, gerlitz.or, alexander.h.duyck, john.r.fastabend,
jeffrey.t.kirsher, netdev, tgraf, pshelar, azhou
In-Reply-To: <CAADnVQKKv43aBFCCaEypAosCf+8K64A2oyYEtxw4jQqY0npV5g@mail.gmail.com>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Tue, 7 Oct 2014 13:28:01 -0700
> On Tue, Oct 7, 2014 at 11:47 AM, David Miller <davem@davemloft.net> wrote:
>>
>> I am totally against boolean "yes/no" protocol specific checksum
>> validation by HW.
>>
>> It's not faster. You have to look at the pseudo-header and bring it into
>> the CPU cache _anyways_, so negating it and 2's complementing it into
>> the CHECKSUM_COMPLETE value for validation is free.
>>
>> There is no performance advantage whatsoever to use another checksumming
>> scheme.
>
> ok, forget faster/slower argument for a second.
> Why is it a bad thing to have HW verifying checksums?
Because you have to change the damn hardware and/or firmware for every
new protocol.
COMPLETE works on _EVERYTHING_ we could ever invent.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: Guenter Roeck @ 2014-10-07 20:33 UTC (permalink / raw)
To: David Miller; +Cc: fabf, linux-kernel, netdev
In-Reply-To: <20141007.161832.453892039501955243.davem@davemloft.net>
On Tue, Oct 07, 2014 at 04:18:32PM -0400, David Miller wrote:
> From: Fabian Frederick <fabf@skynet.be>
> Date: Tue, 7 Oct 2014 22:16:36 +0200
>
> > static values are automatically initialized to NULL
> >
> > Signed-off-by: Fabian Frederick <fabf@skynet.be>
>
> Isn't there some implementation room given to compilers
> as to the representation of true and false?
Not for true/false.
C99 standard, section 7.16:
...
The remaining three macros are suitable for use in #if preprocessing
directives. They are
true
which expands to the integer constant 1,
false
which expands to the integer constant 0, and
...
No idea where the NULL comes into the picture, though.
Guenter
^ permalink raw reply
* Re: [PATCH net-next] icmp6: Add new icmpv6 type for RPL control message
From: David Miller @ 2014-10-07 20:35 UTC (permalink / raw)
To: hannes; +Cc: simon.vincent, netdev
In-Reply-To: <1412713590.11600.5.camel@localhost>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 07 Oct 2014 22:26:30 +0200
> Yep, can you take care of this?
>
> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Of course, done.
^ permalink raw reply
* Re: [PATCH net-next] i40e: skb->xmit_more support
From: David Miller @ 2014-10-07 20:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, dborkman, jeffrey.t.kirsher
In-Reply-To: <1412713823.11091.166.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 07 Oct 2014 13:30:23 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Support skb->xmit_more in i40e is straightforward : we need to move
> around i40e_maybe_stop_tx() call to correctly test netif_xmit_stopped()
> before taking the decision to not kick the NIC.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Intel folks, if I could get a quick review of this that would be great.
Thanks.
^ permalink raw reply
* Re: sunvnet and ->xmit_more
From: Raghuram Kothakota @ 2014-10-07 20:38 UTC (permalink / raw)
To: David Miller; +Cc: sowmini.varadhan, netdev, david.stevens
In-Reply-To: <20141007.153829.1919460115976279645.davem@davemloft.net>
On Oct 7, 2014, at 12:38 PM, David Miller <davem@davemloft.net> wrote:
> From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
> Date: Tue, 7 Oct 2014 15:29:22 -0400
>
>> I'm not sure how this can be useful to sunvnet- in sunvnet's case
>> we send the TX indication at the *start* of a burst, so if xmit_more
>> was set, sure- we can send out another packet immediately, and
>> avoid another START message (which we already do today), but
>> nothing else to be gained from xmit_more?
>
> If you defer that __vnet_tx_trigger() call through all the ->xmit_more
> SKBs, then you are less likely to see the DRING_STOPPED event from the
> peer which will make you have to send a START again.
>
> So, for an xmit_more burst of 3, instead of:
>
> ->ndo_start_xmit()
> __vnet_tx_trigger()
> ->ndo_start_xmit()
> IRQ -> vnet_ack() -> STOPPED
> ->ndo_start_xmit()
> __vnet_tx_trigger()
>
> You would do something like:
>
> ->ndo_start_xmit()
> ->ndo_start_xmit()
> ->ndo_start_xmit()
> __vnet_tx_trigger()
In case of sunvnet, consumer starting as soon as possible would help
as the consumer is slower as it copies the data to local buffers. The recent
change by DLS avoids the copy in the Tx side, so the producer could be
faster than the receiver. If the trigger is sent after n packets, then consumer
will really start after n packets in the ring and it may have lost that much time
to pickup the packets.
-Raghuram
>
>> BTW, I have most of the NAPI done, getting it stress-tested etc
>> (the recent jumbo commit added a few more races between vnet_port_remove
>> and vnet_start_xmit, thanks to the extra clean_timer) but I figure
>> I might as well fully test this internally since net-next is closed
>> for the moment anyway?
>
> Yeah no rush.
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: Alexei Starovoitov @ 2014-10-07 20:43 UTC (permalink / raw)
To: David Miller
Cc: Tom Herbert, Jesse Gross, gerlitz.or@gmail.com, Alexander Duyck,
John Fastabend, Jeff Kirsher, netdev@vger.kernel.org, Thomas Graf,
Pravin Shelar, Andy Zhou
In-Reply-To: <20141007.163239.157997964784151921.davem@davemloft.net>
On Tue, Oct 7, 2014 at 1:32 PM, David Miller <davem@davemloft.net> wrote:
> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Date: Tue, 7 Oct 2014 13:28:01 -0700
>
>> On Tue, Oct 7, 2014 at 11:47 AM, David Miller <davem@davemloft.net> wrote:
>>>
>>> I am totally against boolean "yes/no" protocol specific checksum
>>> validation by HW.
>>>
>>> It's not faster. You have to look at the pseudo-header and bring it into
>>> the CPU cache _anyways_, so negating it and 2's complementing it into
>>> the CHECKSUM_COMPLETE value for validation is free.
>>>
>>> There is no performance advantage whatsoever to use another checksumming
>>> scheme.
>>
>> ok, forget faster/slower argument for a second.
>> Why is it a bad thing to have HW verifying checksums?
>
> Because you have to change the damn hardware and/or firmware for every
> new protocol.
It is true for existing NICs, but it is not true for upcoming devices.
They're exposing packet parsers to users, so we will be able to
program any protocol into the device without reflashing it.
Some of the guys are even allowing reprogramming the parser
while packets are flowing.
^ permalink raw reply
* Re: sunvnet and ->xmit_more
From: David Miller @ 2014-10-07 20:46 UTC (permalink / raw)
To: Raghuram.Kothakota; +Cc: sowmini.varadhan, netdev, david.stevens
In-Reply-To: <9BB04EDE-1842-4DB0-93BE-5186B2D187AB@oracle.com>
From: Raghuram Kothakota <Raghuram.Kothakota@oracle.com>
Date: Tue, 7 Oct 2014 13:38:07 -0700
> In case of sunvnet, consumer starting as soon as possible would help
> as the consumer is slower as it copies the data to local buffers. The recent
> change by DLS avoids the copy in the Tx side, so the producer could be
> faster than the receiver. If the trigger is sent after n packets, then consumer
> will really start after n packets in the ring and it may have lost that much time
> to pickup the packets.
I agree for the first few TX queue entires, or even just the first, but after
that it always pays to defer and decrease the number of hcalls, locks, etc.
Play with it, you'll see.
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: David Miller @ 2014-10-07 20:48 UTC (permalink / raw)
To: alexei.starovoitov
Cc: therbert, jesse, gerlitz.or, alexander.h.duyck, john.r.fastabend,
jeffrey.t.kirsher, netdev, tgraf, pshelar, azhou
In-Reply-To: <CAADnVQJDxPsMeuNmnR5iUwccOKG2A02dZ+3Ae6wGg-RNFPeeeQ@mail.gmail.com>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Tue, 7 Oct 2014 13:43:09 -0700
> On Tue, Oct 7, 2014 at 1:32 PM, David Miller <davem@davemloft.net> wrote:
>> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>> Date: Tue, 7 Oct 2014 13:28:01 -0700
>>
>>> On Tue, Oct 7, 2014 at 11:47 AM, David Miller <davem@davemloft.net> wrote:
>>>>
>>>> I am totally against boolean "yes/no" protocol specific checksum
>>>> validation by HW.
>>>>
>>>> It's not faster. You have to look at the pseudo-header and bring it into
>>>> the CPU cache _anyways_, so negating it and 2's complementing it into
>>>> the CHECKSUM_COMPLETE value for validation is free.
>>>>
>>>> There is no performance advantage whatsoever to use another checksumming
>>>> scheme.
>>>
>>> ok, forget faster/slower argument for a second.
>>> Why is it a bad thing to have HW verifying checksums?
>>
>> Because you have to change the damn hardware and/or firmware for every
>> new protocol.
>
> It is true for existing NICs, but it is not true for upcoming devices.
> They're exposing packet parsers to users, so we will be able to
> program any protocol into the device without reflashing it.
> Some of the guys are even allowing reprogramming the parser
> while packets are flowing.
So we have to write new software in _EVERY_ driver to accomodate this.
That makes zero sense either, and it is unneeded complexity in the
hardware.
COMPLETE works everywhere, on everything, with no driver changes, and
is so much harder to get wrong.
Every protocol specific feature has major downsides whether you choose
to see them or not.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: Fabian Frederick @ 2014-10-07 20:49 UTC (permalink / raw)
To: Guenter Roeck, David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20141007203344.GA4748@roeck-us.net>
> On 07 October 2014 at 22:33 Guenter Roeck <linux@roeck-us.net> wrote:
>
>
> On Tue, Oct 07, 2014 at 04:18:32PM -0400, David Miller wrote:
> > From: Fabian Frederick <fabf@skynet.be>
> > Date: Tue, 7 Oct 2014 22:16:36 +0200
> >
> > > static values are automatically initialized to NULL
> > >
> > > Signed-off-by: Fabian Frederick <fabf@skynet.be>
> >
> > Isn't there some implementation room given to compilers
> > as to the representation of true and false?
>
> Not for true/false.
>
> C99 standard, section 7.16:
>
> ...
> The remaining three macros are suitable for use in #if preprocessing
> directives. They are
>
> true
>
> which expands to the integer constant 1,
>
> false
>
> which expands to the integer constant 0, and
> ...
>
> No idea where the NULL comes into the picture, though.
>
> Guenter
Maybe comment should have been "static values are automatically initialized to
0" then ?
Regards,
Fabian
^ permalink raw reply
* Re: [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: David Miller @ 2014-10-07 20:50 UTC (permalink / raw)
To: fabf; +Cc: linux, netdev, linux-kernel
In-Reply-To: <1559212122.19553.1412714971908.open-xchange@webmail.nmp.skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Tue, 7 Oct 2014 22:49:31 +0200 (CEST)
> Maybe comment should have been "static values are automatically initialized to
> 0" then ?
Yes, that sounds a lot better, please respin.
^ permalink raw reply
* Re: sunvnet and ->xmit_more
From: Sowmini Varadhan @ 2014-10-07 20:51 UTC (permalink / raw)
To: David Miller; +Cc: Raghuram.Kothakota, netdev, david.stevens
In-Reply-To: <20141007.164649.587971614591244924.davem@davemloft.net>
On (10/07/14 16:46), David Miller wrote:
>
> Play with it, you'll see.
at the moment, there are enough fun and games just doing a
"modload -r sunvnet; modload sunvnet" in a loop while running iperf.
I think running stably is as important as tput, no? :-) Lets fix
all the races first.
--Sowmini
^ permalink raw reply
* Re: [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: Hannes Frederic Sowa @ 2014-10-07 20:54 UTC (permalink / raw)
To: Fabian Frederick; +Cc: Guenter Roeck, David Miller, netdev, linux-kernel
In-Reply-To: <1559212122.19553.1412714971908.open-xchange@webmail.nmp.skynet.be>
On Di, 2014-10-07 at 22:49 +0200, Fabian Frederick wrote:
>
> > On 07 October 2014 at 22:33 Guenter Roeck <linux@roeck-us.net> wrote:
> >
> >
> > On Tue, Oct 07, 2014 at 04:18:32PM -0400, David Miller wrote:
> > > From: Fabian Frederick <fabf@skynet.be>
> > > Date: Tue, 7 Oct 2014 22:16:36 +0200
> > >
> > > > static values are automatically initialized to NULL
> > > >
> > > > Signed-off-by: Fabian Frederick <fabf@skynet.be>
> > >
> > > Isn't there some implementation room given to compilers
> > > as to the representation of true and false?
> >
> > Not for true/false.
> >
> > C99 standard, section 7.16:
> >
> > ...
> > The remaining three macros are suitable for use in #if preprocessing
> > directives. They are
> >
> > true
> >
> > which expands to the integer constant 1,
> >
> > false
> >
> > which expands to the integer constant 0, and
> > ...
> >
> > No idea where the NULL comes into the picture, though.
> >
> > Guenter
>
> Maybe comment should have been "static values are automatically initialized to
> 0" then ?
I think David's concern was whether if 0 == false in all situations. It
is pretty clear that static memory is initialized to 0.
Thanks,
Hannes
^ permalink raw reply
* [PATCH V2 net-next] af_unix: remove 0 assignment on static
From: Fabian Frederick @ 2014-10-07 21:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Fabian Frederick, David S. Miller, netdev
static values are automatically initialized to 0
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
V2: replace NULL by 0 in description
net/unix/garbage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/unix/garbage.c b/net/unix/garbage.c
index 9bc73f8..99f7012 100644
--- a/net/unix/garbage.c
+++ b/net/unix/garbage.c
@@ -258,7 +258,7 @@ static void inc_inflight_move_tail(struct unix_sock *u)
list_move_tail(&u->link, &gc_candidates);
}
-static bool gc_in_progress = false;
+static bool gc_in_progress;
#define UNIX_INFLIGHT_TRIGGER_GC 16000
void wait_for_unix_gc(void)
--
1.9.3
^ permalink raw reply related
* Re: [PATCH V2 net-next] af_unix: remove 0 assignment on static
From: David Miller @ 2014-10-07 21:03 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, netdev
In-Reply-To: <1412715735-6757-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Tue, 7 Oct 2014 23:02:15 +0200
> static values are automatically initialized to 0
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> V2: replace NULL by 0 in description
Applied, thanks Fabian.
^ 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