From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43C79C43464 for ; Fri, 18 Sep 2020 18:42:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DBE1321534 for ; Fri, 18 Sep 2020 18:42:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DaC3f1BQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726121AbgIRSmm (ORCPT ); Fri, 18 Sep 2020 14:42:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726115AbgIRSmm (ORCPT ); Fri, 18 Sep 2020 14:42:42 -0400 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A33EDC0613CF for ; Fri, 18 Sep 2020 11:42:41 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id n13so6979976edo.10 for ; Fri, 18 Sep 2020 11:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=j2eYNeg015udNGB8swkWKCandUmqIuS/Xe2LmSRaFMs=; b=DaC3f1BQ+/JwBqOPggYcXO0ttF5AY4WLqev27AoWLLlCjCvOK26VdxXciuVnb+fWYl VzkhKKGO39J2GMO/xm2w/NPxWh7BRRRNiJUcNnMcUYTv/VrVlwAirQDKjEiS4+voEwy7 Ylde2t1knqM0L0way6PjPSNgRAyUDjz9QGp/Zv5zPS8DTHsV0p4bHs47NFg85CbXsCZ+ B2cEmzbNU2zdw6fklLYN8X8Lxelt1SHOpW3VpQxg6p7dAeYz5pRcRY+foBpppQjhO7cq bFlgJtH9JKBJ6PwnbHN4+805r3H46SVvbhIAgpqBl3biqW8f7m4khvNg+1YR5ZTzd3R+ 64sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=j2eYNeg015udNGB8swkWKCandUmqIuS/Xe2LmSRaFMs=; b=mSBTvWH3jkR78pSgJYOZ3NRKvwluUFy51uC/mfkTje3uDzzUMczv+sBtkvrsUJwXkm VPaSZYnkHXvbvsncrf5zyfJrDiLWM77ww/lKwGOUtUfB+ndcoGGq1y5SKdOJCAyFK+l8 bKWsLDEoYGRHo9k2TKb0ntINFJ7ct5zvW5qpJUN9nS7xzuAujT272tlOT4Zq5xIPQVK4 q/nSPLb0QSHuer52sh8VmxjS2LJCWUazgzHe5HjLFroBv2Rs5OQZ0Yg5lNSgMDo7CVir BeT5VN1WcSWPj41CKrRCL3X16OYEnp7cYwcBKl652fTZm/HSjBwFzWNgeP2ePv6XExBQ TqxA== X-Gm-Message-State: AOAM531zuplvUsmfr9WfZark0E5nEb4NGxOeHiDngscPCojBRilof2V7 W3XgXe2ooqA2xuismtoDruqqIRxiWlytLsXfeNmA+c92vqoYqw== X-Google-Smtp-Source: ABdhPJzdTUwevCCSRXf9B3zvn2ga/zq/Rfplxg6Gxc20JE22mIWDN9Ea6BmwCQHJYNUIR6y0HTuXds4izsjqThL0FVE= X-Received: by 2002:a50:e807:: with SMTP id e7mr40685696edn.84.1600454560171; Fri, 18 Sep 2020 11:42:40 -0700 (PDT) MIME-Version: 1.0 References: <87lfh7fkqs.fsf@toke.dk> In-Reply-To: <87lfh7fkqs.fsf@toke.dk> Reply-To: ThomasPtacek@gmail.com From: Thomas Ptacek Date: Fri, 18 Sep 2020 13:42:28 -0500 Message-ID: Subject: Re: bpf_redirect and xdpgeneric To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: xdp-newbies@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: xdp-newbies@vger.kernel.org The setup is pretty simple. There's an eno1 (igb driver), to which our default route points. On the same box are several VMs. There's a tap interface (for each VM, call it tapX). Traffic for a VM flows in from the Internet on eno1 and is directed to tapX; the response traffic flows in the other direction. I'm deliberately simplifying here: eno1 runs an XDP program that does some lightweight IP rewriting from anycast addresses to internal VM addresses on ingress. eno1's XDP program currently XDP_PASS's rewritten packets to the IP stack, where they're routed to the VM's tap. This works fine. tapX runs an XDP program that does the same rewriting in reverse. Right now, it also XDP_PASS's packets to the stack, which also works --- the stack routes response traffic out eno1. I'm playing with XDP_REDIRECT'ing instead of XDP_PASS'ing. I have the ifindexes and MAC addresses (and those of IP neighbors) in a map --- a normal HASH map, not a DEVMAP. Using that map, I can successfully redirect traffic from tapX to arbitrary other tap interfaces. What I can't do is redirect packets from tapX to eno1, which is what the system actually needs to do. --- Thomas H. Ptacek On Fri, Sep 18, 2020 at 5:21 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Thomas Ptacek writes: > > > Weird question: > > > > Should there be a reason for me to expect bpf_redirect to fail when > > redirecting, in XDP, to the egress of an xdpgeneric device? > > What does 'the egress of an xdpgeneric device' mean, exactly? I.e., > could you share some more details of your setup, please? > > In general, mixing native and generic mode XDP is not likely to work > well... > > -Toke > --=20 --- Thomas H. Ptacek 312-231-7805