From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net-next] sctp: define sctp_packet_gso_append to build GSO frames Date: Wed, 13 Jun 2018 19:05:59 -0700 (PDT) Message-ID: <20180613.190559.1358933130944096340.davem@davemloft.net> References: <20180614004643.GA12409@neilslaptop.think-freely.org> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: lucien.xin@gmail.com, netdev@vger.kernel.org, linux-sctp@vger.kernel.org, marcelo.leitner@gmail.com, eric.dumazet@gmail.com To: nhorman@tuxdriver.com Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:37136 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935616AbeFNCGC (ORCPT ); Wed, 13 Jun 2018 22:06:02 -0400 In-Reply-To: <20180614004643.GA12409@neilslaptop.think-freely.org> Sender: netdev-owner@vger.kernel.org List-ID: From: Neil Horman Date: Wed, 13 Jun 2018 20:46:43 -0400 > Do you have any performance numbers to compare with and without this > patch? Adding a function like this implies that any fixes that go > into skb_gro_receive now need to be evaluated for this function too, > which means theres an implied overhead in maintaining it. If we're > signing up for that, I'd like to know that theres a significant > performance benefit. Neil, I asked Xin and Marcelo to do this. There is no reason for GSO code to use a GRO helper. And this is, in particular, blocking some skb_gro_receive() surgery I plan to perform.