From owner-freebsd-arm@FreeBSD.ORG Sun Jun 29 17:57:48 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E0F7964; Sun, 29 Jun 2014 17:57:48 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BE412C23; Sun, 29 Jun 2014 17:57:47 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id mc6so4298240lab.27 for ; Sun, 29 Jun 2014 10:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=s3S9MGdkayLGmg9ljUSbH1FE2eENoT7dIZOwagTSVIg=; b=pHNP9x1fgi7S6lkRk6L5ji5ggZr/fFlzlLyg/xqPITv9Tov+TYNywtfQ5Df1EBOycM XPHUxVZdzy2tdQL90PIZ4CtLsVykEyFiSuxt7wQM92/nkrBspEs4zWG+DDJhx3D/YSgz b9wTZ3573UuoZpwcxZDeoHdCEUZNzQodCd5+AFMPRDoOv/wTGH85UtC5oALPMUKKiK5i tJrWyhGtf9Ii7EJ6Lz6VsWela8Qi7i5hxPeQFvO9PHEQAAfgMBRIt/9dvzaBHogwIq9E BHux7lyrcHeyRV0osfRsej546ffOUGMxF5JTRJhvp7StM0h3+ao2rTH9FAEffbT+GueE R3ag== MIME-Version: 1.0 X-Received: by 10.152.204.102 with SMTP id kx6mr27632805lac.32.1404064665332; Sun, 29 Jun 2014 10:57:45 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.22.232 with HTTP; Sun, 29 Jun 2014 10:57:45 -0700 (PDT) In-Reply-To: <20140629040150.GO1560@funkthat.com> References: <20140629033823.GN1560@funkthat.com> <20140629040150.GO1560@funkthat.com> Date: Sun, 29 Jun 2014 13:57:45 -0400 X-Google-Sender-Auth: i1bMgpTEX36PHRNCZrUIpyC66Ig Message-ID: Subject: Re: arm alignment faults... From: Patrick Kelsey To: Adrian Chadd , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 17:57:48 -0000 On Sun, Jun 29, 2014 at 12:01 AM, John-Mark Gurney wrote: > Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 -0700: > > On 28 June 2014 20:38, John-Mark Gurney wrote: > > > So, one of the little projects I'd like to see is the removal of > > > ETHER_ALIGN from the tree.. This bogosity can (and does) cause the use > > > of bouncing durning DMA ops on all ethernet frames... > > Now that I think about it, total removal may not be necessary, just > the requirement to use it... If the ethernet dma engine can do half > word aligned dma, then there would be benifit on those to keep > ETHER_ALIGN... > > > Well, as long as you're not doing it by forcing the various CPUs to > > handle unaligned accesses. > > Hard to do on armv4 which I don't believe supports unaligned access... > > > The cost of those unaligned accesses on some CPUs that support them is > > not trivial. We benchmarked some of the ARM cores at Qualcomm back > > when looking to migrate stuff to ARM and it wasn't very quick. > > I plan on fixing the TCP/IP stack to copy data to an aligned buffer > (maybe only if the original buffer isn't aligned) on the stack when > __NO_STRICT_ALIGNMENT is not defined... I can't see how copying the > entire packet is cheaper than copying 20 bytes or so... > > I like the idea of getting away from the concept of ETHER_ALIGN. This will also be nice when feeding the TCP/IP stack using netmap. There's no facility in netmap for landing receive data at an offset in the word-aligned ring buffer, so using netmap to receive frames for the TCP/IP stack relies on unaligned access support from the platform. For platforms where there is not unaligned access support, or it comes with a noticeable penalty, it would become easier to consider using a netmap + TCP/IP stack approach to some problems. I wonder if it's really worth having the copy action be conditional on an alignment check - it seems to me the cycle savings would be modest at best for the half-word-aligned-capable ethernet dma engine crowd, at the cost of having two different header access paths in the code. Also, getting away from the current business of modifying the mbuf via in-place header byteswaps will make the stack friendlier for building things that inspect packets up through tcp headers/connection lookup and then possibly decide to bridge them out some interface as a result (as then in such cases, one won't have to ever unwind the changes to mbuf contents). If I'm thinking about this right, pr_input_t will have to grow a new parameter to support passing the on-stack IP header pointer along. I suppose this could be considered a generic 'encapsulation header' pointer, so as not to taint the protosw interface with something ip-specific. -Patrick