From nobody Tue Feb 08 22:38:15 2022 X-Original-To: freebsd-transport@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6AC1919ACA68 for ; Tue, 8 Feb 2022 22:38:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtdG154nQz3GGq for ; Tue, 8 Feb 2022 22:38:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-qt1-f175.google.com with SMTP id s1so379099qtw.9 for ; Tue, 08 Feb 2022 14:38:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JFWXbELk4nkGeqzNtny5GzdordWTkJQ3fkwrtRO/ppM=; b=sZJonGvJMsSu3ZLe1M1BLFUT2x4ebrmSucfOHtDnlxxmnoeE+A7HKonExKUdw2iGMa ul+7xLWH9KRtR8Jhr/eyoEnIZu3HwZhSwIsqQuGbmnuuSyZthXUgdOxEdlaF4cnC4DpP ZVLfxYqLeGTe6ZwLpa1eMg9ptD8iwx8kh4iW9o3xeqvw1vBqV6B/PTtoWQe8k9rrrqzv yE78mg9pGx4y78wp7YEJVr7SNt4Q2S4+4JwxeOMoq63uaTSdOjU0DNK8Rv3xRpLw62n5 eMOC1/SIBlnNCNTDf4b7p906CaDoYkMfxaEVSqvzyZcVR8xvokwfPO2NpT7g8oPnt+gZ hPGw== X-Gm-Message-State: AOAM532I+zDHM7CJq3rjT8stH50GERi36SQWVC/ii76klsgFnZQFsYfS xZtlmakEECtjsG9QoCLDziglS0sER3EDzpTLluzhU1/a X-Google-Smtp-Source: ABdhPJy37bPGGWNphw67se3Pu13wAZH1NWqurVK1NLuzUXI3j98lX8oeS41esduD6SOWWBfiXOmCRp1GD6T7++9G/pw= X-Received: by 2002:ac8:5f48:: with SMTP id y8mr4478937qta.284.1644359907431; Tue, 08 Feb 2022 14:38:27 -0800 (PST) List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-transport List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-transport@freebsd.org X-BeenThere: freebsd-transport@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Adrian Chadd Date: Tue, 8 Feb 2022 14:38:15 -0800 Message-ID: Subject: Re: panic: syncache: mbuf too small To: Drew Gallatin Cc: "Bjoern A. Zeeb" , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JtdG154nQz3GGq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of adrianchadd@gmail.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=adrianchadd@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-transport@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.160.175:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-transport]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.160.175:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Tue, 8 Feb 2022 at 14:34, Drew Gallatin wrote: > > I don't think the size has changed recently. However, there is a size di= fference for pkthdrs (and hence MHLEN) on 32-bit platforms vs 64-bit platfo= rms. > > There are a number of bad ways to handle this. Eg, don't permit Ipv6 on = these interfaces, make these interfaces chain their headers, assuming they = can do s/g dma, make them copy to a contiguous buffer. Make mbufs bigger. = All of the things I can think of are ugly. (a) yeah, some of the wifi firmware based things (bcom, realtek) have some weird ass requirements where the FW/PHY/MAC/802.11 headers end up needing to be in a contig buffer due to hardware/firmware requirements. You can sometimes chain things afterwards, but eg on the bwi/bwn firmware NICs you really need all of that data in the first sg buffer the firmware sees. (b) i think honestly we can just linearise the mbufs for the wifi drivers that need a big headroom nowdays, it's not a huge deal and in a lot of cases the linux drivers do? did? end up doing this to simplify handling. -adrian