[RFC v2 0/3] add TSO / A-MSDU TX for iwlwifi

2015-08-19 Thread Emmanuel Grumbach
We enable TSO to get a lot of data at once to build A-MSDUs.
Our hardware doesn't have (yet) TCP CSUM offload, so we do
it manually. TSO won't be enabled on hardware that don't
support CSUM offload in release code, computing TCP CSUM
in the driver is just a way to start coding the flows.
This is why the CSUM offload implementation in the driver
in so bad in terms of efficiency. I preferred to have the
flows as close as they will be when the hardware will be
able to the CSUM than to try to seek efficiency.
The hardware that will have CSUM offload will still require
the driver to split the skb in software including the
IP / TCP header copy and update etc...

We could have enabled A-MSDU based on xmit-more, but the
rationale of using LSO is that when using pfifo-fast,
the Qdisc gets one packet and dequeues is straight away
which limits the possibility to get a lot of packets at
once. (Am I right here?).

A note about A-MSDUs for non-wireless people:
*
An A-MSDU is a aggregated frame. It is one big 802.11
packet that contains several subframes. Each subframe
is a TCP segment. One A-MSDU is represented by one single
skb which means that we need to copy / duplicate the TCP
/ IP / SNAP headers in one single skb. This is why those
headers are copied to a separate page: that page is added
multiple times to the skb with different offsets. Each
subframes needs at least 2 frags: 1 for the headers, 1 (or
more) for the payload.

I am quite a newbie in skb handling, so I guess that this
code can be improved. I have tested it decently using iperf,
but this doesn't mean that there are no issues using other
applications. We are enabling pktgen on TCP (using patches
that were sent a year ago or so) to test the different
layouts of the skb (payload partition amongst the header
and the different frags).

I'll be very happy to get comments on that code, this is
why I am sending it to netdev as well since the TSO experts
are there :)

Emmanuel Grumbach (3):
  iwlwifi: mvm: add real TSO implementation
  iwlwifi: mvm: allow to create A-MSDUs from a large send
  iwlwifi: mvm: transfer the truesize to the last TSO segment

 drivers/net/wireless/iwlwifi/mvm/mac80211.c |   3 +-
 drivers/net/wireless/iwlwifi/mvm/sta.c  |   4 +-
 drivers/net/wireless/iwlwifi/mvm/sta.h  |   6 +-
 drivers/net/wireless/iwlwifi/mvm/tx.c   | 669 ++--
 4 files changed, 647 insertions(+), 35 deletions(-)

-- 
2.1.4

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


Re: [RFC v2 0/3] add TSO / A-MSDU TX for iwlwifi

2015-08-19 Thread Eric Dumazet
On Wed, 2015-08-19 at 15:59 +0300, Emmanuel Grumbach wrote:

 We could have enabled A-MSDU based on xmit-more, but the
 rationale of using LSO is that when using pfifo-fast,
 the Qdisc gets one packet and dequeues is straight away
 which limits the possibility to get a lot of packets at
 once. (Am I right here?).

No, you are not ;)

Key point for xmit_more is BQL being implemented in your driver.

Relevant code is in try_bulk_dequeue_skb()


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


Re: [RFC v2 0/3] add TSO / A-MSDU TX for iwlwifi

2015-08-19 Thread Eric Dumazet
On Wed, 2015-08-19 at 17:00 +, Grumbach, Emmanuel wrote:
 
 On 08/19/2015 07:08 PM, Eric Dumazet wrote:
  On Wed, 2015-08-19 at 15:07 +, Grumbach, Emmanuel wrote:
  
  I'll look at it.
  I was almost starting to implement that but then I thought with another
  (good?) reason to use LSO. LSO gives me the guarantee that the packet is
  directed to one peer, which might not be the case with xmit_more since
  we have one Qdisc for several clients in case we are in AP mode.
  Building an A-MSDU for several clients is not possible, at least not for
  several client in the L2 (different MAC addresses).
  LSO avoids this problem completely.
  
  Then, simply calling skb_gso_segment() from the driver might be enough,
  and less work for you.
  
  This would even support TSO on IPv6
  
 
 Well... I did take care of IPv6.

net/core/tso.c does not yet handle IPv6


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


Re: [RFC v2 0/3] add TSO / A-MSDU TX for iwlwifi

2015-08-19 Thread Grumbach, Emmanuel


On 08/19/2015 07:08 PM, Eric Dumazet wrote:
 On Wed, 2015-08-19 at 15:07 +, Grumbach, Emmanuel wrote:
 
 I'll look at it.
 I was almost starting to implement that but then I thought with another
 (good?) reason to use LSO. LSO gives me the guarantee that the packet is
 directed to one peer, which might not be the case with xmit_more since
 we have one Qdisc for several clients in case we are in AP mode.
 Building an A-MSDU for several clients is not possible, at least not for
 several client in the L2 (different MAC addresses).
 LSO avoids this problem completely.
 
 Then, simply calling skb_gso_segment() from the driver might be enough,
 and less work for you.
 
 This would even support TSO on IPv6
 

Well... I did take care of IPv6.

 segs = skb_gso_segment(skb, tp-dev-features 
 ~(NETIF_F_TSO | NETIF_F_TSO6));
 
 

Thing is that our HW layers are currently implemented to receive one skb
per 802.11 packet. So that if I call skb_gso_segment, I'd have to
re-assemble the segs into one A-MSDU which would translate one skb.
I guess I could change the HW layer in the driver to be able to get a
list of skbs and make a single packet out of it, but that'd be tricky or
wasteful. skb_gso_segment will duplicate the wifi header while it is not
needed. Only the TCP / IP / SNAP headers need to be duplicated.
Moreover, each subframe in the A-MSDU needs it own subframe header (same
format as ethhdr) and there is also some padding in there. So that would
be even more complicated IMHO.
My code doesn't copy any payload. Only the headers. This is why I
thought it'd be better than segmenting and then re-assembling.
I did call skb_gso_segment if I get lots of payload in the header (more
than 2 * mss) in order to simplify the implementation.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC v2 0/3] add TSO / A-MSDU TX for iwlwifi

2015-08-19 Thread Eric Dumazet
On Wed, 2015-08-19 at 17:56 +, Grumbach, Emmanuel wrote:
 

 So I feel that making net/core/tso.c more complicated just because of
 our craziness seems an overkill to me.
 I'll try a bit harder to see how I can use net/core/tso.c, but I have to
 say I am pessimistic.

net/core/tso.c is WIP, feel free to expand it to make it more generic
and meet your needs.

The point is : we want a core infrastructure, not something that each
individual driver implements in ~500 lines of code :(


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