Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp158889ybl; Tue, 20 Aug 2019 17:31:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqzlH4JQszTS/wEWApCOyYgp4lIr4I5EEm+Zs7R3vMR8cxgk62IJKkJtJnF7km0lgkQas973 X-Received: by 2002:a17:90a:342d:: with SMTP id o42mr2716511pjb.27.1566347480332; Tue, 20 Aug 2019 17:31:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566347480; cv=none; d=google.com; s=arc-20160816; b=cKjL7kMt8aiSzSNa3rqmfVVsqb678teD5J0/ru6JF1iX6acgTeWqLz0pH7gI6UfSEA TEk8mggmOhNS1WbjBxvKttHG/Y0t2R1ciBgZl/2VXOE8ryzt/JGNweV65ouOw5Kc98W3 qD0TXvSy2wRG2EVG/tY2lmhU3gLDyZNEUf2dpve6PdJOTMU+CkuNTFOuCgaEOYRQ+Nzy Mc2shUsc6ExwS8WPPdk1ynTyKAMi2guh+S92Csjtb+DbgDQwCrjniirysLkryBTO4z72 JLKVysiFCYyUBQlZDAkA21DfxSQUY9LHYYL3m+lZ0B+XH1EqniilWVL8rrJRUEyEOijE aRbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=FXqq5agnMhybNrO23ARWsSKRNVHc8uwYX6TeUD3ACrU=; b=ylSsoyS5sk3WLd3i8Z92H+DtoHSFwRsv0BAFC9i35aKaJzKW8l5kNSoAX7CKeVcKYD MVJVImE6jCXX+thJbYMl7oM+VhU4Tys0g2MjGAv6KLvwDpQW5dnfx/iGRSMpVdvGswms efUOmZAkSe1Mnxw6F8SHmQenkQ0SEGox5f/slFeSAjDGCusiVr4NWkGN2ULSaQRs/vRD GFNKPhPtg4si3ARjG9Dp9Td3ZdBdSbBESfazOLn3mi4oCVRWJVXnWsJDxwHAnXl8Ly6L a2gkZlqn5cU+NafGtbhfRBdkeVOiA2ZxkKiSxld6aVf7DxC97crxksngmoBdA5DQUMsX +wAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@lunn.ch header.s=20171124 header.b=v7xXKbSE; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n13si14224828pff.46.2019.08.20.17.31.01; Tue, 20 Aug 2019 17:31:20 -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; dkim=fail header.i=@lunn.ch header.s=20171124 header.b=v7xXKbSE; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726363AbfHUACF (ORCPT + 99 others); Tue, 20 Aug 2019 20:02:05 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:46888 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726141AbfHUACF (ORCPT ); Tue, 20 Aug 2019 20:02:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=FXqq5agnMhybNrO23ARWsSKRNVHc8uwYX6TeUD3ACrU=; b=v7xXKbSE/kXKAj3899T00ra+G0 3VdR9y6xjSny+QEGRAy1XnJCpBF3GrRKsNGQotR6CdLMKE6TxpX0CfMQmn35lcCL242wZqt+RQYMO REqcatuA7o1ySYt0k+vwRo+SuJRL96CsqsM8qpZXFu86ghZ0VmQwRYAlKsucZxG9zuZs=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1i0E4Z-0001Ct-3i; Wed, 21 Aug 2019 02:01:55 +0200 Date: Wed, 21 Aug 2019 02:01:55 +0200 From: Andrew Lunn To: Sabrina Dubroca Cc: Antoine Tenart , Igor Russkikh , "davem@davemloft.net" , "f.fainelli@gmail.com" , "hkallweit1@gmail.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "thomas.petazzoni@bootlin.com" , "alexandre.belloni@bootlin.com" , "allan.nielsen@microchip.com" , "camelia.groza@nxp.com" , Simon Edelhaus , Pavel Belous Subject: Re: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure Message-ID: <20190821000155.GA4285@lunn.ch> References: <20190808140600.21477-1-antoine.tenart@bootlin.com> <20190808140600.21477-7-antoine.tenart@bootlin.com> <20190813085817.GA3200@kwain> <20190813131706.GE15047@lunn.ch> <2e3c2307-d414-a531-26cb-064e05fa01fc@aquantia.com> <20190816132959.GC8697@bistromath.localdomain> <20190820100140.GA3292@kwain> <20190820144119.GA28714@bistromath.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190820144119.GA28714@bistromath.localdomain> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > If you look at IPsec offloading, the networking stack builds up the > ESP header, and passes the unencrypted data down to the driver. I'm > wondering if the same would be possible with MACsec offloading: the > macsec virtual interface adds the header (and maybe a dummy ICV), and > then the HW does the encryption. In case of HW that needs to add the > sectag itself, the driver would first strip the headers that the stack > created. On receive, the driver would recreate a sectag and the macsec > interface would just skip all verification (decrypt, PN). Hi Sabrina I assume the software implementation cannot make use of TSO or GSO, letting the hardware segment a big buffer up into Ethernet frames? When using hardware MACSEC, is it possible to enable these? By the time the frames have reach the PHY GSO has been done. So it sees a stream of frames it needs to encode/decode. But if you are suggesting the extra headers are added by the virtual interface, i don't think GSO can be used? My guess would be, we get a performance boost from using hardware MAC sec, but there will also be a performance boost if GSO can be enabled when it was disabled before. Andrew