From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: problems with SCTP GSO Date: Mon, 11 Jun 2018 20:29:05 -0700 (PDT) Message-ID: <20180611.202905.1954825345357429286.davem@davemloft.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: lucien.xin@gmail.com, edumazet@google.com, netdev@vger.kernel.org To: marcelo.leitner@gmail.com Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:59366 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932499AbeFLD33 (ORCPT ); Mon, 11 Jun 2018 23:29:29 -0400 Sender: netdev-owner@vger.kernel.org List-ID: I would like to bring up some problems with the current GSO implementation in SCTP. The most important for me right now is that SCTP uses "skb_gro_receive()" to build "GSO" frames :-( Really it just ends up using the slow path (basically, label 'merge' and onwards). So, using a GRO helper to build GSO packets is not great. I want to make major surgery here and the only way I can is if it is exactly the GRO demuxing path that uses skb_gro_receive(). Those paths pass in the list head from the NAPI struct that initiated the GRO code paths. That makes it easy for me to change this to use a list_head or a hash chain. Probably in the short term SCTP should just have a private helper that builds the frag list, appending 'skb' to 'head'. In the long term, SCTP should use the page frags just like TCP to append the data when building GSO frames. Then it could actually be offloaded and passed into drivers without linearizing.