From owner-svn-src-head@freebsd.org Wed Oct 21 19:24:22 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22AE6A1B7BC; Wed, 21 Oct 2015 19:24:22 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB3F31CB5; Wed, 21 Oct 2015 19:24:21 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id t9LJOKRv078835; Wed, 21 Oct 2015 19:24:20 GMT (envelope-from ian@FreeBSD.org) Received: (from ian@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id t9LJOKk1078834; Wed, 21 Oct 2015 19:24:20 GMT (envelope-from ian@FreeBSD.org) Message-Id: <201510211924.t9LJOKk1078834@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ian set sender to ian@FreeBSD.org using -f From: Ian Lepore Date: Wed, 21 Oct 2015 19:24:20 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r289716 - head/sys/mips/mips X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 19:24:22 -0000 Author: ian Date: Wed Oct 21 19:24:20 2015 New Revision: 289716 URL: https://svnweb.freebsd.org/changeset/base/289716 Log: Treat mbufs as cacheline-aligned. Even when the transfer begins at an offset within the buffer to align the L3 headers we know the buffer itself was allocated and sized on cacheline boundaries and we don't need to preserve partitial cachelines at the start and end of the buffer when doing busdma sync operations. Modified: head/sys/mips/mips/busdma_machdep.c Modified: head/sys/mips/mips/busdma_machdep.c ============================================================================== --- head/sys/mips/mips/busdma_machdep.c Wed Oct 21 19:16:13 2015 (r289715) +++ head/sys/mips/mips/busdma_machdep.c Wed Oct 21 19:24:20 2015 (r289716) @@ -951,6 +951,8 @@ _bus_dmamap_load_buffer(bus_dma_tag_t dm if (segs == NULL) segs = dmat->segments; + if ((flags & BUS_DMA_LOAD_MBUF) != 0) + map->flags |= DMAMAP_CACHE_ALIGNED; if ((dmat->flags & BUS_DMA_COULD_BOUNCE) != 0) { _bus_dmamap_count_pages(dmat, map, pmap, buf, buflen, flags); @@ -1071,10 +1073,16 @@ bus_dmamap_sync_buf(vm_offset_t buf, int * prevent a data loss we save these chunks in temporary buffer * before invalidation and restore them afer it. * - * If the aligned flag is set the buffer came from our allocator caches - * which are always sized and aligned to cacheline boundaries, so we can - * skip preserving nearby data if a transfer is unaligned (especially - * it's likely to not end on a boundary). + * If the aligned flag is set the buffer is either an mbuf or came from + * our allocator caches. In both cases they are always sized and + * aligned to cacheline boundaries, so we can skip preserving nearby + * data if a transfer appears to overlap cachelines. An mbuf in + * particular will usually appear to be overlapped because of offsetting + * within the buffer to align the L3 headers, but we know that the bytes + * preceeding that offset are part of the same mbuf memory and are not + * unrelated adjacent data (and a rule of mbuf handling is that the cpu + * is not allowed to touch the mbuf while dma is in progress, including + * header fields). */ if (aligned) { size_cl = 0;