Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2807842imm; Wed, 3 Oct 2018 09:26:31 -0700 (PDT) X-Google-Smtp-Source: ACcGV63JELy0oyV1l0/syQ/YZhJYGt2pPiZG4uZGt/XF9jj1VIqcolcHzAGqK6MJe3r49nNlGvQ0 X-Received: by 2002:a62:cc4:: with SMTP id 65-v6mr2411206pfm.127.1538583991002; Wed, 03 Oct 2018 09:26:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538583990; cv=none; d=google.com; s=arc-20160816; b=pWKD+dfGr2vz/Q8XQmD5/yf/Tlsceyr0LjzDk79QkM3L5VbOquEKh2mh/hm3z6naNz 5P94Hx/B6+u2CIe40nL7YgiHbXI0oHORcGq4xEjrCC6bEp66z6wU+5Jby+i+lLx7UKn/ 7/85hbiao92MMQ0c9npKkT37MeUewT4yHar3M5gl+BCSYB8HDk+4kdsaoUSgEwyGp9HO jzHa1bJmRkAk2wv68X3SNhBKA9benX63xcWS/EZRNXkol2rr73ragj25ZQhBBH1c/O/K G5M3VQUK2ZHCvb1Pw/qFPhnRddEtKPcYUw4iwufGaoe+s9yHyCm/CqEDZLXJQTQS1ltK hJYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version; bh=4RRpNhUqRwlFX1g3/aytEC8KjKf0bNcZ/rMKBa71jVg=; b=wIZN6L8lt/BUdtlpfdhwW0jFMVdCtoNL0c4wC4elfxYKLHgYf2SofXhqec8Ypygw5J IV51umRTOaMxfmfA6qwL6eXzo8eaMRgqIcC/IkxznLDszpnvAOnbId8BnWk60fP2uyok rN8rGZdnFlWtF/PeerfoxDIDcWnvC5etq7zmuViG4ZDEEvg6BhXHtn7h9D+B6Bc90Cul /axpRyqUdcb+EI+72fTaPsGrWvXejfnH2j/KTvQfHLn4shkMEnUCsY41AgYZU0y0voNV m8etvCDY+IqgI0+8RhjV8Gtp0MHAdcb8ESFugcZ0uMTgGNDwNVTOtqMEMUsOyo7ggno5 ixjQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d32-v6si1959467pla.93.2018.10.03.09.26.05; Wed, 03 Oct 2018 09:26:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727164AbeJCXO6 (ORCPT + 99 others); Wed, 3 Oct 2018 19:14:58 -0400 Received: from imap1.codethink.co.uk ([176.9.8.82]:53382 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726811AbeJCXO6 (ORCPT ); Wed, 3 Oct 2018 19:14:58 -0400 Received: from [192.168.122.135] (helo=_) by imap1.codethink.co.uk with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1g7jy8-0003m0-QO; Wed, 03 Oct 2018 17:25:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 03 Oct 2018 17:25:48 +0100 From: Ben Dooks To: David Laight Cc: netdev@vger.kernel.org, oneukum@suse.com, davem@davemloft.net, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kernel@lists.codethink.co.uk Subject: RE: [PATCH] usbnet: smsc95xx: simplify tx_fixup code In-Reply-To: <55e4b55bae6148b18a27a23aab7d7501@AcuMS.aculab.com> References: <59988ed22559410881addfecf58335eb@AcuMS.aculab.com> <20181002165602.21033-1-ben.dooks@codethink.co.uk> <55e4b55bae6148b18a27a23aab7d7501@AcuMS.aculab.com> Message-ID: <3cc20777c2d8747898a8b7148a046cbb@codethink.co.uk> X-Sender: ben.dooks@codethink.co.uk User-Agent: Roundcube Webmail/1.1.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-10-03 14:36, David Laight wrote: > From: Ben Dooks >> Sent: 02 October 2018 17:56 >> >> The smsc95xx_tx_fixup is doing multiple calls to skb_push() to >> put an 8-byte command header onto the packet. It would be easier >> to do one skb_push() and then copy the data in once the push is >> done. >> >> Signed-off-by: Ben Dooks >> --- >> drivers/net/usb/smsc95xx.c | 25 +++++++++++++------------ >> 1 file changed, 13 insertions(+), 12 deletions(-) >> >> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c >> index cb19aea139d3..813ab93ee2c3 100644 >> --- a/drivers/net/usb/smsc95xx.c >> +++ b/drivers/net/usb/smsc95xx.c >> @@ -2006,6 +2006,7 @@ static struct sk_buff *smsc95xx_tx_fixup(struct >> usbnet *dev, >> bool csum = skb->ip_summed == CHECKSUM_PARTIAL; >> int overhead = csum ? SMSC95XX_TX_OVERHEAD_CSUM : >> SMSC95XX_TX_OVERHEAD; >> u32 tx_cmd_a, tx_cmd_b; >> + void *ptr; > > It might be useful to define a structure for the header. > You might need to find the 'store unaligned 32bit word' macro though. > (Actually that will probably be better than the memcpy() which might > end up doing memory-memory copies rather than storing the register.) > Although if/when you add the tx alignment that won't be needed because > the > header will be aligned. Ok, might be worth doing. I did try to do a "u32 tx_cmd[2]" but the code generated ended up storing stuff onto the stack before copying into the packet. I agree that possibly going to the "put_unaligned" function might be nicer too. If we did enable tx-align all the time then we'd not have to care about the alignment, but I didn't want to do that if possible as that would end up sending up to 3 bytes extra per packet. I am trying not too do too many changes at one time to allow roll back. >> /* We do not advertise SG, so skbs should be already linearized */ >> BUG_ON(skb_shinfo(skb)->nr_frags); >> @@ -2019,6 +2020,9 @@ static struct sk_buff *smsc95xx_tx_fixup(struct >> usbnet *dev, >> return NULL; >> } >> >> + tx_cmd_b = (u32)skb->len; >> + tx_cmd_a = tx_cmd_b | TX_CMD_A_FIRST_SEG_ | TX_CMD_A_LAST_SEG_; >> + >> if (csum) { >> if (skb->len <= 45) { >> /* workaround - hardware tx checksum does not work >> @@ -2035,21 +2039,18 @@ static struct sk_buff >> *smsc95xx_tx_fixup(struct usbnet *dev, >> skb_push(skb, 4); >> cpu_to_le32s(&csum_preamble); > > Not related, but csum_preamble = cpu_to_le32(csum_preamble) is likely > to > generate better code (at least for some architectures). > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, > MK1 1PT, UK > Registration No: 1397386 (Wales)