RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-17 Thread David Laight 
From: KY Srinivasan
> Sent: 16 September 2015 23:58
...
> > I think we get that.  The question is does the Remote NDIS header and
> > packet info actually need to be a part of the header data?  I would
> > argue that it probably doesn't.
> >
> > So for example in netvsc_start_xmit it looks like you are calling
> > init_page_array in order to populate a set of page buffers, but the
> > first buffer for the Remote NDIS protocol is populated as a separate
> > page and offset.  As such it doesn't seem like it necessarily needs to
> > be a part of the header data but could be maintained perhaps in a
> > separate ring buffer, or perhaps just be a separate page that you break
> > up to use for each header.
> 
> You are right; the rndis header can be built as a separate fragment and sent.
> Indeed this is what we were doing earlier - on the outgoing path we would 
> allocate
> memory for the rndis header. My goal was to avoid this allocation on every 
> packet being
> sent and I decided to use the headroom instead. If we can completely avoid 
> all memory
> allocation for rndis header, it makes a significant perf difference:
...


So just preallocate the header space as a fixed buffer for each ring entry
(or tx frame).

If you allocate a fixed buffer for each ring entry you may find there are
performance gains from copying small fragments into the buffer instead
of doing whatever mapping operations are required.

David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-17 Thread Vitaly Kuznetsov 
David Miller  writes:

> From: David Laight 
> Date: Wed, 16 Sep 2015 16:25:03 +
>
>> Am I right in thinking this is adding an extra 96 unused bytes to the front
>> of almost all skb just so that hyper-v can make its link level header
>> contiguous with whatever follows (IP header ?).
>> 
>> Doesn't sound ideal.
>
> Agreed, this is rediculous, and the entire stack will incur this cost
> just because hyperv is enabled in the kernel config.

That's what 'RFC' in the subject was about :-)

We already have a precedent of increasing LL_MAX_HEADER globaly because
of a config option (CONFIG_MAC80211_MESH) but Hyper-V needs more.

-- 
  Vitaly
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-17 Thread KY Srinivasan 


> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Thursday, September 17, 2015 1:38 AM
> To: KY Srinivasan <k...@microsoft.com>; Alexander Duyck
> <alexander.du...@gmail.com>; Haiyang Zhang <haiya...@microsoft.com>;
> Vitaly Kuznetsov <vkuzn...@redhat.com>; netdev@vger.kernel.org
> Cc: David S. Miller <da...@davemloft.net>; linux-ker...@vger.kernel.org;
> Jason Wang <jasow...@redhat.com>
> Subject: RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V
> 
> From: KY Srinivasan
> > Sent: 16 September 2015 23:58
> ...
> > > I think we get that.  The question is does the Remote NDIS header and
> > > packet info actually need to be a part of the header data?  I would
> > > argue that it probably doesn't.
> > >
> > > So for example in netvsc_start_xmit it looks like you are calling
> > > init_page_array in order to populate a set of page buffers, but the
> > > first buffer for the Remote NDIS protocol is populated as a separate
> > > page and offset.  As such it doesn't seem like it necessarily needs to
> > > be a part of the header data but could be maintained perhaps in a
> > > separate ring buffer, or perhaps just be a separate page that you break
> > > up to use for each header.
> >
> > You are right; the rndis header can be built as a separate fragment and 
> > sent.
> > Indeed this is what we were doing earlier - on the outgoing path we would
> allocate
> > memory for the rndis header. My goal was to avoid this allocation on every
> packet being
> > sent and I decided to use the headroom instead. If we can completely avoid 
> > all
> memory
> > allocation for rndis header, it makes a significant perf difference:
> ...
> 
> 
> So just preallocate the header space as a fixed buffer for each ring entry
> (or tx frame).
> 
> If you allocate a fixed buffer for each ring entry you may find there are
> performance gains from copying small fragments into the buffer instead
> of doing whatever mapping operations are required.
> 
>   David

Yes; I could do that. My original goal of asking for additional head room was 
to avoid having
any allocation in the transmit path. I did not realize that all I had done was 
push the allocation to a
different spot since the head room I was asking was greater than the default 
head room on skb allocation.

I think I can achieve my original goal of not having any allocation in the send 
path by carefully using the
memory available in the skb:

1. I am going to separately handle the rndis header and this can be packed in 
the default headroom
available in the skb.
2. I will use the scratch area in the skb to stash away the state that needs to 
persist. This is the state needed
to cleanup the guest state after we get the send_complete packet.

Regards,

K. Y 
 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-17 Thread David Miller 
From: KY Srinivasan 
Date: Thu, 17 Sep 2015 15:14:05 +

> I think I can achieve my original goal of not having any allocation
> in the send path by carefully using the memory available in the skb:

Please stop flat-out ignoring David L.'s suggestion.

Have a pre-cooked ring of buffers for these descriptors that you can
point the chip at.  No per-packet allocation is necessary at all.

If you play games with SKBs you will get burned.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-17 Thread David Miller 
From: KY Srinivasan 
Date: Thu, 17 Sep 2015 19:52:01 +

> 
> 
>> -Original Message-
>> Have a pre-cooked ring of buffers for these descriptors that you can
>> point the chip at.  No per-packet allocation is necessary at all.
> 
> Even if I had a ring of buffers, I would still need to manage the life cycle
> of these buffers - selecting an unused one on the transmit path and marking
> it used (atomically).

Have one per TX ring entry, then the lifetime matches the lifetime of the
TX entry itself and therefore you need do nothing.

That's the whole idea.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-17 Thread KY Srinivasan 


> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, September 17, 2015 11:52 AM
> To: KY Srinivasan <k...@microsoft.com>
> Cc: david.lai...@aculab.com; alexander.du...@gmail.com; Haiyang Zhang
> <haiya...@microsoft.com>; vkuzn...@redhat.com; netdev@vger.kernel.org;
> linux-ker...@vger.kernel.org; jasow...@redhat.com
> Subject: Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V
> 
> From: KY Srinivasan <k...@microsoft.com>
> Date: Thu, 17 Sep 2015 15:14:05 +
> 
> > I think I can achieve my original goal of not having any allocation
> > in the send path by carefully using the memory available in the skb:
> 
> Please stop flat-out ignoring David L.'s suggestion.

I am sorry; I did not mean to convey that impression.

> 
> Have a pre-cooked ring of buffers for these descriptors that you can
> point the chip at.  No per-packet allocation is necessary at all.

Even if I had a ring of buffers, I would still need to manage the life cycle
of these buffers - selecting an unused one on the transmit path and marking
it used (atomically). Once the transmit completes (as indicated by the transmit 
complete
callback) this buffer needs to be marked free. I can certainly make these 
operations
efficient and  lock-free, but they are still at some level an allocation/free
operation albeit potentially more efficient than having the kernel allocate the 
memory.
 
> 
> If you play games with SKBs you will get burned.

I will implement Dave L's suggestion. However, I am curious as to why you would 
consider
my proposed usage of the skb headroom and the control buffer area in skb as 
non-standard
usage.

Regards,

K. Y 


  
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-17 Thread KY Srinivasan 


> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, September 17, 2015 1:11 PM
> To: KY Srinivasan <k...@microsoft.com>
> Cc: david.lai...@aculab.com; alexander.du...@gmail.com; Haiyang Zhang
> <haiya...@microsoft.com>; vkuzn...@redhat.com; netdev@vger.kernel.org;
> linux-ker...@vger.kernel.org; jasow...@redhat.com
> Subject: Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V
> 
> From: KY Srinivasan <k...@microsoft.com>
> Date: Thu, 17 Sep 2015 19:52:01 +
> 
> >
> >
> >> -Original Message-
> >> Have a pre-cooked ring of buffers for these descriptors that you can
> >> point the chip at.  No per-packet allocation is necessary at all.
> >
> > Even if I had a ring of buffers, I would still need to manage the life cycle
> > of these buffers - selecting an unused one on the transmit path and marking
> > it used (atomically).
> 
> Have one per TX ring entry, then the lifetime matches the lifetime of the
> TX entry itself and therefore you need do nothing.

Yes, I understand. Unfortunately, the ring buffer used on Hyper-V to send the 
packets to the host is not
managed as a traditional TX ring entries - it is not fixed size and a given 
packet can wrap around and lastly, I think
the management of space on the ring buffer is not tied to the act of completing 
the send operation. That is why
we have an explicit "send complete" message.

I am working on moving the model to more closely match the hardware model but 
it will take some time.
For now, I will implement a very light weight mechanism for managing the 
additional memory needed.

Regards,

K. Y
> 
> That's the whole idea.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-16 Thread Haiyang Zhang 


> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Wednesday, September 16, 2015 11:50 AM
> To: netdev@vger.kernel.org
> Cc: David S. Miller ; linux-ker...@vger.kernel.org;
> KY Srinivasan ; Haiyang Zhang
> ; Jason Wang 
> Subject: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V
> 
> Commit b08cc79155fc26d0d112b1470d1ece5034651a4b ("hv_netvsc: Eliminate
>  memory allocation in the packet send path") introduced skb headroom
> request for Hyper-V netvsc driver:
> 
>max_needed_headroom = sizeof(struct hv_netvsc_packet) +
>sizeof(struct rndis_message) +
>NDIS_VLAN_PPI_SIZE + NDIS_CSUM_PPI_SIZE +
>NDIS_LSO_PPI_SIZE + NDIS_HASH_PPI_SIZE;
>...
>net->needed_headroom = max_needed_headroom;
> 
> max_needed_headroom is 220 bytes, it significantly exceeds the
> LL_MAX_HEADER setting. This causes each skb to be cloned on send path,
> e.g. for IPv4 case we fall into the following clause
> (ip_finish_output2()):
> 
> if (unlikely(skb_headroom(skb) < hh_len && dev->header_ops)) {
> ...
> skb2 = skb_realloc_headroom(skb, LL_RESERVED_SPACE(dev));
> ...
> }
> 
> leading to a significant performance regression. Increase LL_MAX_HEADER
> to make it suitable for netvsc, make it 224 to be 16-aligned.
> Alternatively we could (partially) revert the commit which introduced
> skb
> headroom request restoring manual memory allocation on transmit path.
> 
> Signed-off-by: Vitaly Kuznetsov 
> ---
>  include/linux/netdevice.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 88a0069..7233790 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -132,7 +132,9 @@ static inline bool dev_xmit_complete(int rc)
>   *   used.
>   */
> 
> -#if defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
> +#if IS_ENABLED(CONFIG_HYPERV_NET)
> +# define LL_MAX_HEADER 224
> +#elif defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
>  # if defined(CONFIG_MAC80211_MESH)
>  #  define LL_MAX_HEADER 128
>  # else

Thanks for the patch.
To avoid we forget to update that 224 number when we add more things
into netvsc header, I suggest that we define a macro in netdevice.h such 
as:
#define HVNETVSC_MAX_HEADER 224
#define LL_MAX_HEADER HVNETVSC_MAX_HEADER

And, put a note in netvsc code saying the header reservation shouldn't 
exceed HVNETVSC_MAX_HEADER, or you need to update HVNETVSC_MAX_HEADER.

Thanks,
- Haiyang




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-16 Thread David Laight 
From: Haiyang Zhang
> Sent: 16 September 2015 17:09
> > -Original Message-
> > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> > Sent: Wednesday, September 16, 2015 11:50 AM
> > To: netdev@vger.kernel.org
> > Cc: David S. Miller ; linux-ker...@vger.kernel.org;
> > KY Srinivasan ; Haiyang Zhang
> > ; Jason Wang 
> > Subject: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V
> >
> > Commit b08cc79155fc26d0d112b1470d1ece5034651a4b ("hv_netvsc: Eliminate
> >  memory allocation in the packet send path") introduced skb headroom
> > request for Hyper-V netvsc driver:
> >
> >max_needed_headroom = sizeof(struct hv_netvsc_packet) +
> >sizeof(struct rndis_message) +
> >NDIS_VLAN_PPI_SIZE + NDIS_CSUM_PPI_SIZE +
> >NDIS_LSO_PPI_SIZE + NDIS_HASH_PPI_SIZE;
> >...
> >net->needed_headroom = max_needed_headroom;
> >
> > max_needed_headroom is 220 bytes, it significantly exceeds the
> > LL_MAX_HEADER setting. This causes each skb to be cloned on send path,
> > e.g. for IPv4 case we fall into the following clause
> > (ip_finish_output2()):
> >
> > if (unlikely(skb_headroom(skb) < hh_len && dev->header_ops)) {
> > ...
> > skb2 = skb_realloc_headroom(skb, LL_RESERVED_SPACE(dev));
> > ...
> > }
> >
> > leading to a significant performance regression. Increase LL_MAX_HEADER
> > to make it suitable for netvsc, make it 224 to be 16-aligned.
> > Alternatively we could (partially) revert the commit which introduced
> > skb
> > headroom request restoring manual memory allocation on transmit path.
> >
> > Signed-off-by: Vitaly Kuznetsov 
> > ---
> >  include/linux/netdevice.h | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index 88a0069..7233790 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -132,7 +132,9 @@ static inline bool dev_xmit_complete(int rc)
> >   * used.
> >   */
> >
> > -#if defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
> > +#if IS_ENABLED(CONFIG_HYPERV_NET)
> > +# define LL_MAX_HEADER 224
> > +#elif defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
> >  # if defined(CONFIG_MAC80211_MESH)
> >  #  define LL_MAX_HEADER 128
> >  # else
> 
> Thanks for the patch.
> To avoid we forget to update that 224 number when we add more things
> into netvsc header, I suggest that we define a macro in netdevice.h such
> as:
> #define HVNETVSC_MAX_HEADER 224
> #define LL_MAX_HEADER HVNETVSC_MAX_HEADER
> 
> And, put a note in netvsc code saying the header reservation shouldn't
> exceed HVNETVSC_MAX_HEADER, or you need to update HVNETVSC_MAX_HEADER.

Am I right in thinking this is adding an extra 96 unused bytes to the front
of almost all skb just so that hyper-v can make its link level header
contiguous with whatever follows (IP header ?).

Doesn't sound ideal.

David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-16 Thread KY Srinivasan 


> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Wednesday, September 16, 2015 9:25 AM
> To: Haiyang Zhang <haiya...@microsoft.com>; Vitaly Kuznetsov
> <vkuzn...@redhat.com>; netdev@vger.kernel.org
> Cc: David S. Miller <da...@davemloft.net>; linux-ker...@vger.kernel.org;
> KY Srinivasan <k...@microsoft.com>; Jason Wang <jasow...@redhat.com>
> Subject: RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-
> V
> 
> From: Haiyang Zhang
> > Sent: 16 September 2015 17:09
> > > -Original Message-
> > > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> > > Sent: Wednesday, September 16, 2015 11:50 AM
> > > To: netdev@vger.kernel.org
> > > Cc: David S. Miller <da...@davemloft.net>; linux-
> ker...@vger.kernel.org;
> > > KY Srinivasan <k...@microsoft.com>; Haiyang Zhang
> > > <haiya...@microsoft.com>; Jason Wang <jasow...@redhat.com>
> > > Subject: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-
> V
> > >
> > > Commit b08cc79155fc26d0d112b1470d1ece5034651a4b ("hv_netvsc:
> Eliminate
> > >  memory allocation in the packet send path") introduced skb headroom
> > > request for Hyper-V netvsc driver:
> > >
> > >max_needed_headroom = sizeof(struct hv_netvsc_packet) +
> > >sizeof(struct rndis_message) +
> > >NDIS_VLAN_PPI_SIZE + NDIS_CSUM_PPI_SIZE +
> > >NDIS_LSO_PPI_SIZE + NDIS_HASH_PPI_SIZE;
> > >...
> > >net->needed_headroom = max_needed_headroom;
> > >
> > > max_needed_headroom is 220 bytes, it significantly exceeds the
> > > LL_MAX_HEADER setting. This causes each skb to be cloned on send
> path,
> > > e.g. for IPv4 case we fall into the following clause
> > > (ip_finish_output2()):
> > >
> > > if (unlikely(skb_headroom(skb) < hh_len && dev->header_ops)) {
> > > ...
> > > skb2 = skb_realloc_headroom(skb, LL_RESERVED_SPACE(dev));
> > > ...
> > > }
> > >
> > > leading to a significant performance regression. Increase
> LL_MAX_HEADER
> > > to make it suitable for netvsc, make it 224 to be 16-aligned.
> > > Alternatively we could (partially) revert the commit which introduced
> > > skb
> > > headroom request restoring manual memory allocation on transmit path.
> > >
> > > Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
> > > ---
> > >  include/linux/netdevice.h | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > > index 88a0069..7233790 100644
> > > --- a/include/linux/netdevice.h
> > > +++ b/include/linux/netdevice.h
> > > @@ -132,7 +132,9 @@ static inline bool dev_xmit_complete(int rc)
> > >   *   used.
> > >   */
> > >
> > > -#if defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
> > > +#if IS_ENABLED(CONFIG_HYPERV_NET)
> > > +# define LL_MAX_HEADER 224
> > > +#elif defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
> > >  # if defined(CONFIG_MAC80211_MESH)
> > >  #  define LL_MAX_HEADER 128
> > >  # else
> >
> > Thanks for the patch.
> > To avoid we forget to update that 224 number when we add more things
> > into netvsc header, I suggest that we define a macro in netdevice.h such
> > as:
> > #define HVNETVSC_MAX_HEADER 224
> > #define LL_MAX_HEADER HVNETVSC_MAX_HEADER
> >
> > And, put a note in netvsc code saying the header reservation shouldn't
> > exceed HVNETVSC_MAX_HEADER, or you need to update
> HVNETVSC_MAX_HEADER.
> 
> Am I right in thinking this is adding an extra 96 unused bytes to the front
> of almost all skb just so that hyper-v can make its link level header
> contiguous with whatever follows (IP header ?).
> 
> Doesn't sound ideal.

Remote NDIS is the protocol used to send packets from the guest to the host. 
Every packet
needs to be decorated with the RNDIS header and the maximum room needed for the 
RNDIS
header is the hreadroom we want.

K. Y
> 
>   David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-16 Thread David Miller 
From: David Laight 
Date: Wed, 16 Sep 2015 16:25:03 +

> Am I right in thinking this is adding an extra 96 unused bytes to the front
> of almost all skb just so that hyper-v can make its link level header
> contiguous with whatever follows (IP header ?).
> 
> Doesn't sound ideal.

Agreed, this is rediculous, and the entire stack will incur this cost
just because hyperv is enabled in the kernel config.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-16 Thread Alexander Duyck 

On 09/16/2015 10:55 AM, KY Srinivasan wrote:



-Original Message-
From: David Laight [mailto:david.lai...@aculab.com]
Sent: Wednesday, September 16, 2015 9:25 AM
To: Haiyang Zhang <haiya...@microsoft.com>; Vitaly Kuznetsov
<vkuzn...@redhat.com>; netdev@vger.kernel.org
Cc: David S. Miller <da...@davemloft.net>; linux-ker...@vger.kernel.org;
KY Srinivasan <k...@microsoft.com>; Jason Wang <jasow...@redhat.com>
Subject: RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-
V

From: Haiyang Zhang

Sent: 16 September 2015 17:09

-Original Message-
From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
Sent: Wednesday, September 16, 2015 11:50 AM
To: netdev@vger.kernel.org
Cc: David S. Miller <da...@davemloft.net>; linux-

ker...@vger.kernel.org;

KY Srinivasan <k...@microsoft.com>; Haiyang Zhang
<haiya...@microsoft.com>; Jason Wang <jasow...@redhat.com>
Subject: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-

V

Commit b08cc79155fc26d0d112b1470d1ece5034651a4b ("hv_netvsc:

Eliminate

  memory allocation in the packet send path") introduced skb headroom
request for Hyper-V netvsc driver:

max_needed_headroom = sizeof(struct hv_netvsc_packet) +
sizeof(struct rndis_message) +
NDIS_VLAN_PPI_SIZE + NDIS_CSUM_PPI_SIZE +
NDIS_LSO_PPI_SIZE + NDIS_HASH_PPI_SIZE;
...
net->needed_headroom = max_needed_headroom;

max_needed_headroom is 220 bytes, it significantly exceeds the
LL_MAX_HEADER setting. This causes each skb to be cloned on send

path,

e.g. for IPv4 case we fall into the following clause
(ip_finish_output2()):

if (unlikely(skb_headroom(skb) < hh_len && dev->header_ops)) {
 ...
 skb2 = skb_realloc_headroom(skb, LL_RESERVED_SPACE(dev));
 ...
}

leading to a significant performance regression. Increase

LL_MAX_HEADER

to make it suitable for netvsc, make it 224 to be 16-aligned.
Alternatively we could (partially) revert the commit which introduced
skb
headroom request restoring manual memory allocation on transmit path.

Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
---
  include/linux/netdevice.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 88a0069..7233790 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -132,7 +132,9 @@ static inline bool dev_xmit_complete(int rc)
   *used.
   */

-#if defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
+#if IS_ENABLED(CONFIG_HYPERV_NET)
+# define LL_MAX_HEADER 224
+#elif defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
  # if defined(CONFIG_MAC80211_MESH)
  #  define LL_MAX_HEADER 128
  # else

Thanks for the patch.
To avoid we forget to update that 224 number when we add more things
into netvsc header, I suggest that we define a macro in netdevice.h such
as:
#define HVNETVSC_MAX_HEADER 224
#define LL_MAX_HEADER HVNETVSC_MAX_HEADER

And, put a note in netvsc code saying the header reservation shouldn't
exceed HVNETVSC_MAX_HEADER, or you need to update

HVNETVSC_MAX_HEADER.

Am I right in thinking this is adding an extra 96 unused bytes to the front
of almost all skb just so that hyper-v can make its link level header
contiguous with whatever follows (IP header ?).

Doesn't sound ideal.

Remote NDIS is the protocol used to send packets from the guest to the host. 
Every packet
needs to be decorated with the RNDIS header and the maximum room needed for the 
RNDIS
header is the hreadroom we want.


I think we get that.  The question is does the Remote NDIS header and 
packet info actually need to be a part of the header data?  I would 
argue that it probably doesn't.


So for example in netvsc_start_xmit it looks like you are calling 
init_page_array in order to populate a set of page buffers, but the 
first buffer for the Remote NDIS protocol is populated as a separate 
page and offset.  As such it doesn't seem like it necessarily needs to 
be a part of the header data but could be maintained perhaps in a 
separate ring buffer, or perhaps just be a separate page that you break 
up to use for each header.


- Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-16 Thread Alexander Duyck 

On 09/16/2015 03:57 PM, KY Srinivasan wrote:



-Original Message-
From: Alexander Duyck [mailto:alexander.du...@gmail.com]
Sent: Wednesday, September 16, 2015 2:39 PM
To: KY Srinivasan <k...@microsoft.com>; David Laight
<david.lai...@aculab.com>; Haiyang Zhang <haiya...@microsoft.com>;
Vitaly Kuznetsov <vkuzn...@redhat.com>; netdev@vger.kernel.org
Cc: David S. Miller <da...@davemloft.net>; linux-ker...@vger.kernel.org;
Jason Wang <jasow...@redhat.com>
Subject: Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

On 09/16/2015 10:55 AM, KY Srinivasan wrote:

-Original Message-
From: David Laight [mailto:david.lai...@aculab.com]
Sent: Wednesday, September 16, 2015 9:25 AM
To: Haiyang Zhang <haiya...@microsoft.com>; Vitaly Kuznetsov
<vkuzn...@redhat.com>; netdev@vger.kernel.org
Cc: David S. Miller <da...@davemloft.net>; linux-ker...@vger.kernel.org;
KY Srinivasan <k...@microsoft.com>; Jason Wang <jasow...@redhat.com>
Subject: RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-
V

From: Haiyang Zhang

Sent: 16 September 2015 17:09

-Original Message-
From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
Sent: Wednesday, September 16, 2015 11:50 AM
To: netdev@vger.kernel.org
Cc: David S. Miller <da...@davemloft.net>; linux-

ker...@vger.kernel.org;

KY Srinivasan <k...@microsoft.com>; Haiyang Zhang
<haiya...@microsoft.com>; Jason Wang <jasow...@redhat.com>
Subject: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-

V

Commit b08cc79155fc26d0d112b1470d1ece5034651a4b ("hv_netvsc:

Eliminate

   memory allocation in the packet send path") introduced skb headroom
request for Hyper-V netvsc driver:

 max_needed_headroom = sizeof(struct hv_netvsc_packet) +
 sizeof(struct rndis_message) +
 NDIS_VLAN_PPI_SIZE + NDIS_CSUM_PPI_SIZE +
 NDIS_LSO_PPI_SIZE + NDIS_HASH_PPI_SIZE;
 ...
 net->needed_headroom = max_needed_headroom;

max_needed_headroom is 220 bytes, it significantly exceeds the
LL_MAX_HEADER setting. This causes each skb to be cloned on send

path,

e.g. for IPv4 case we fall into the following clause
(ip_finish_output2()):

if (unlikely(skb_headroom(skb) < hh_len && dev->header_ops)) {
  ...
  skb2 = skb_realloc_headroom(skb, LL_RESERVED_SPACE(dev));
  ...
}

leading to a significant performance regression. Increase

LL_MAX_HEADER

to make it suitable for netvsc, make it 224 to be 16-aligned.
Alternatively we could (partially) revert the commit which introduced
skb
headroom request restoring manual memory allocation on transmit path.

Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
---
   include/linux/netdevice.h | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 88a0069..7233790 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -132,7 +132,9 @@ static inline bool dev_xmit_complete(int rc)
*   used.
*/

-#if defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
+#if IS_ENABLED(CONFIG_HYPERV_NET)
+# define LL_MAX_HEADER 224
+#elif defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
   # if defined(CONFIG_MAC80211_MESH)
   #  define LL_MAX_HEADER 128
   # else

Thanks for the patch.
To avoid we forget to update that 224 number when we add more things
into netvsc header, I suggest that we define a macro in netdevice.h such
as:
#define HVNETVSC_MAX_HEADER 224
#define LL_MAX_HEADER HVNETVSC_MAX_HEADER

And, put a note in netvsc code saying the header reservation shouldn't
exceed HVNETVSC_MAX_HEADER, or you need to update

HVNETVSC_MAX_HEADER.

Am I right in thinking this is adding an extra 96 unused bytes to the front
of almost all skb just so that hyper-v can make its link level header
contiguous with whatever follows (IP header ?).

Doesn't sound ideal.

Remote NDIS is the protocol used to send packets from the guest to the host.

Every packet

needs to be decorated with the RNDIS header and the maximum room needed

for the RNDIS

header is the hreadroom we want.

I think we get that.  The question is does the Remote NDIS header and
packet info actually need to be a part of the header data?  I would
argue that it probably doesn't.

So for example in netvsc_start_xmit it looks like you are calling
init_page_array in order to populate a set of page buffers, but the
first buffer for the Remote NDIS protocol is populated as a separate
page and offset.  As such it doesn't seem like it necessarily needs to
be a part of the header data but could be maintained perhaps in a
separate ring buffer, or perhaps just be a separate page that you break
up to use for each header.

You are right; the rndis header can be built as a separate fragment and sent.
Indeed this is what we were doing earlier - on the out

RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-16 Thread KY Srinivasan 


> -Original Message-
> From: Alexander Duyck [mailto:alexander.du...@gmail.com]
> Sent: Wednesday, September 16, 2015 2:39 PM
> To: KY Srinivasan <k...@microsoft.com>; David Laight
> <david.lai...@aculab.com>; Haiyang Zhang <haiya...@microsoft.com>;
> Vitaly Kuznetsov <vkuzn...@redhat.com>; netdev@vger.kernel.org
> Cc: David S. Miller <da...@davemloft.net>; linux-ker...@vger.kernel.org;
> Jason Wang <jasow...@redhat.com>
> Subject: Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V
> 
> On 09/16/2015 10:55 AM, KY Srinivasan wrote:
> >
> >> -Original Message-
> >> From: David Laight [mailto:david.lai...@aculab.com]
> >> Sent: Wednesday, September 16, 2015 9:25 AM
> >> To: Haiyang Zhang <haiya...@microsoft.com>; Vitaly Kuznetsov
> >> <vkuzn...@redhat.com>; netdev@vger.kernel.org
> >> Cc: David S. Miller <da...@davemloft.net>; linux-ker...@vger.kernel.org;
> >> KY Srinivasan <k...@microsoft.com>; Jason Wang <jasow...@redhat.com>
> >> Subject: RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-
> >> V
> >>
> >> From: Haiyang Zhang
> >>> Sent: 16 September 2015 17:09
> >>>> -Original Message-
> >>>> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> >>>> Sent: Wednesday, September 16, 2015 11:50 AM
> >>>> To: netdev@vger.kernel.org
> >>>> Cc: David S. Miller <da...@davemloft.net>; linux-
> >> ker...@vger.kernel.org;
> >>>> KY Srinivasan <k...@microsoft.com>; Haiyang Zhang
> >>>> <haiya...@microsoft.com>; Jason Wang <jasow...@redhat.com>
> >>>> Subject: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-
> >> V
> >>>> Commit b08cc79155fc26d0d112b1470d1ece5034651a4b ("hv_netvsc:
> >> Eliminate
> >>>>   memory allocation in the packet send path") introduced skb headroom
> >>>> request for Hyper-V netvsc driver:
> >>>>
> >>>> max_needed_headroom = sizeof(struct hv_netvsc_packet) +
> >>>> sizeof(struct rndis_message) +
> >>>> NDIS_VLAN_PPI_SIZE + NDIS_CSUM_PPI_SIZE +
> >>>> NDIS_LSO_PPI_SIZE + NDIS_HASH_PPI_SIZE;
> >>>> ...
> >>>> net->needed_headroom = max_needed_headroom;
> >>>>
> >>>> max_needed_headroom is 220 bytes, it significantly exceeds the
> >>>> LL_MAX_HEADER setting. This causes each skb to be cloned on send
> >> path,
> >>>> e.g. for IPv4 case we fall into the following clause
> >>>> (ip_finish_output2()):
> >>>>
> >>>> if (unlikely(skb_headroom(skb) < hh_len && dev->header_ops)) {
> >>>>  ...
> >>>>  skb2 = skb_realloc_headroom(skb, LL_RESERVED_SPACE(dev));
> >>>>  ...
> >>>> }
> >>>>
> >>>> leading to a significant performance regression. Increase
> >> LL_MAX_HEADER
> >>>> to make it suitable for netvsc, make it 224 to be 16-aligned.
> >>>> Alternatively we could (partially) revert the commit which introduced
> >>>> skb
> >>>> headroom request restoring manual memory allocation on transmit path.
> >>>>
> >>>> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
> >>>> ---
> >>>>   include/linux/netdevice.h | 4 +++-
> >>>>   1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> >>>> index 88a0069..7233790 100644
> >>>> --- a/include/linux/netdevice.h
> >>>> +++ b/include/linux/netdevice.h
> >>>> @@ -132,7 +132,9 @@ static inline bool dev_xmit_complete(int rc)
> >>>>* used.
> >>>>*/
> >>>>
> >>>> -#if defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
> >>>> +#if IS_ENABLED(CONFIG_HYPERV_NET)
> >>>> +# define LL_MAX_HEADER 224
> >>>> +#elif defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
> >>>>   # if defined(CONFIG_MAC80211_MESH)
> >>>>   #  define LL_MAX_HEADER 128
> >>>>   # else
> >>> Thanks for the patch.
> >>> To avoid we forget to update that 224 number when w

RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-16 Thread KY Srinivasan 


> -Original Message-
> From: Alexander Duyck [mailto:alexander.du...@gmail.com]
> Sent: Wednesday, September 16, 2015 4:49 PM
> To: KY Srinivasan <k...@microsoft.com>; David Laight
> <david.lai...@aculab.com>; Haiyang Zhang <haiya...@microsoft.com>;
> Vitaly Kuznetsov <vkuzn...@redhat.com>; netdev@vger.kernel.org
> Cc: David S. Miller <da...@davemloft.net>; linux-ker...@vger.kernel.org;
> Jason Wang <jasow...@redhat.com>
> Subject: Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V
> 
> On 09/16/2015 03:57 PM, KY Srinivasan wrote:
> >
> >> -Original Message-
> >> From: Alexander Duyck [mailto:alexander.du...@gmail.com]
> >> Sent: Wednesday, September 16, 2015 2:39 PM
> >> To: KY Srinivasan <k...@microsoft.com>; David Laight
> >> <david.lai...@aculab.com>; Haiyang Zhang <haiya...@microsoft.com>;
> >> Vitaly Kuznetsov <vkuzn...@redhat.com>; netdev@vger.kernel.org
> >> Cc: David S. Miller <da...@davemloft.net>; linux-ker...@vger.kernel.org;
> >> Jason Wang <jasow...@redhat.com>
> >> Subject: Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-
> V
> >>
> >> On 09/16/2015 10:55 AM, KY Srinivasan wrote:
> >>>> -Original Message-
> >>>> From: David Laight [mailto:david.lai...@aculab.com]
> >>>> Sent: Wednesday, September 16, 2015 9:25 AM
> >>>> To: Haiyang Zhang <haiya...@microsoft.com>; Vitaly Kuznetsov
> >>>> <vkuzn...@redhat.com>; netdev@vger.kernel.org
> >>>> Cc: David S. Miller <da...@davemloft.net>; linux-
> ker...@vger.kernel.org;
> >>>> KY Srinivasan <k...@microsoft.com>; Jason Wang
> <jasow...@redhat.com>
> >>>> Subject: RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for
> Hyper-
> >>>> V
> >>>>
> >>>> From: Haiyang Zhang
> >>>>> Sent: 16 September 2015 17:09
> >>>>>> -Original Message-
> >>>>>> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> >>>>>> Sent: Wednesday, September 16, 2015 11:50 AM
> >>>>>> To: netdev@vger.kernel.org
> >>>>>> Cc: David S. Miller <da...@davemloft.net>; linux-
> >>>> ker...@vger.kernel.org;
> >>>>>> KY Srinivasan <k...@microsoft.com>; Haiyang Zhang
> >>>>>> <haiya...@microsoft.com>; Jason Wang <jasow...@redhat.com>
> >>>>>> Subject: [PATCH net-next RFC] net: increase LL_MAX_HEADER for
> Hyper-
> >>>> V
> >>>>>> Commit b08cc79155fc26d0d112b1470d1ece5034651a4b
> ("hv_netvsc:
> >>>> Eliminate
> >>>>>>memory allocation in the packet send path") introduced skb
> headroom
> >>>>>> request for Hyper-V netvsc driver:
> >>>>>>
> >>>>>>  max_needed_headroom = sizeof(struct hv_netvsc_packet) +
> >>>>>>  sizeof(struct rndis_message) +
> >>>>>>  NDIS_VLAN_PPI_SIZE + 
> >>>>>> NDIS_CSUM_PPI_SIZE +
> >>>>>>  NDIS_LSO_PPI_SIZE + 
> >>>>>> NDIS_HASH_PPI_SIZE;
> >>>>>>  ...
> >>>>>>  net->needed_headroom = max_needed_headroom;
> >>>>>>
> >>>>>> max_needed_headroom is 220 bytes, it significantly exceeds the
> >>>>>> LL_MAX_HEADER setting. This causes each skb to be cloned on send
> >>>> path,
> >>>>>> e.g. for IPv4 case we fall into the following clause
> >>>>>> (ip_finish_output2()):
> >>>>>>
> >>>>>> if (unlikely(skb_headroom(skb) < hh_len && dev->header_ops)) {
> >>>>>>   ...
> >>>>>>   skb2 = skb_realloc_headroom(skb, LL_RESERVED_SPACE(dev));
> >>>>>>   ...
> >>>>>> }
> >>>>>>
> >>>>>> leading to a significant performance regression. Increase
> >>>> LL_MAX_HEADER
> >>>>>> to make it suitable for netvsc, make it 224 to be 16-aligned.
> >>>>>> Alternatively we could (partially) revert the commit which introduced
> >>>>>> skb
> >>>>>> headroom request restoring manual m

Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

2015-09-16 Thread Alexander Duyck 

On 09/16/2015 09:25 AM, David Laight wrote:

From: Haiyang Zhang

Sent: 16 September 2015 17:09

-Original Message-
From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
Sent: Wednesday, September 16, 2015 11:50 AM
To: netdev@vger.kernel.org
Cc: David S. Miller ; linux-ker...@vger.kernel.org;
KY Srinivasan ; Haiyang Zhang
; Jason Wang 
Subject: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

Commit b08cc79155fc26d0d112b1470d1ece5034651a4b ("hv_netvsc: Eliminate
  memory allocation in the packet send path") introduced skb headroom
request for Hyper-V netvsc driver:

max_needed_headroom = sizeof(struct hv_netvsc_packet) +
sizeof(struct rndis_message) +
NDIS_VLAN_PPI_SIZE + NDIS_CSUM_PPI_SIZE +
NDIS_LSO_PPI_SIZE + NDIS_HASH_PPI_SIZE;
...
net->needed_headroom = max_needed_headroom;

max_needed_headroom is 220 bytes, it significantly exceeds the
LL_MAX_HEADER setting. This causes each skb to be cloned on send path,
e.g. for IPv4 case we fall into the following clause
(ip_finish_output2()):

if (unlikely(skb_headroom(skb) < hh_len && dev->header_ops)) {
 ...
 skb2 = skb_realloc_headroom(skb, LL_RESERVED_SPACE(dev));
 ...
}

leading to a significant performance regression. Increase LL_MAX_HEADER
to make it suitable for netvsc, make it 224 to be 16-aligned.
Alternatively we could (partially) revert the commit which introduced
skb
headroom request restoring manual memory allocation on transmit path.

Signed-off-by: Vitaly Kuznetsov 
---
  include/linux/netdevice.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 88a0069..7233790 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -132,7 +132,9 @@ static inline bool dev_xmit_complete(int rc)
   *used.
   */

-#if defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
+#if IS_ENABLED(CONFIG_HYPERV_NET)
+# define LL_MAX_HEADER 224
+#elif defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
  # if defined(CONFIG_MAC80211_MESH)
  #  define LL_MAX_HEADER 128
  # else

Thanks for the patch.
To avoid we forget to update that 224 number when we add more things
into netvsc header, I suggest that we define a macro in netdevice.h such
as:
#define HVNETVSC_MAX_HEADER 224
#define LL_MAX_HEADER HVNETVSC_MAX_HEADER

And, put a note in netvsc code saying the header reservation shouldn't
exceed HVNETVSC_MAX_HEADER, or you need to update HVNETVSC_MAX_HEADER.

Am I right in thinking this is adding an extra 96 unused bytes to the front
of almost all skb just so that hyper-v can make its link level header
contiguous with whatever follows (IP header ?).

Doesn't sound ideal.


Actually it will probably add closer to 128 unused bytes per frame since 
an skb allocation is rounded off to the nearest cache line in terms of size.


Is there a reason why this buffer info and descriptor like thing even 
needs to be in the packet header?  From what I can tell it was being 
allocated separately before.  Why not just maintain a ring of them if 
you need to keep them around and want to avoid having to reallocate them 
for the next transmit?  Also I don't know if the layout  matters but it 
probably wouldn't hurt to go through with pahole and clean the 
hv_netvsc_packet structure up.  You could probably save yourself 
something like 20+ bytes just doing that.


- Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html