Re: [Coin] IPv6 Switch ML @ IETF 105 Hackathon

Marie-Jose Montpetit <> Sun, 21 July 2019 11:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5E7112011D for <>; Sun, 21 Jul 2019 04:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MfKjjdxVO3Wt for <>; Sun, 21 Jul 2019 04:54:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F82B12011B for <>; Sun, 21 Jul 2019 04:54:53 -0700 (PDT)
Received: by with SMTP id y26so35672259qto.4 for <>; Sun, 21 Jul 2019 04:54:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UaDZMAwmx6Zc/9HvUCVuQHK+naAGMCh1r8otkIRM0ow=; b=cPA8/wiUpbHxfWJQo5keHhQbrZmpHj1ObH8DIh8iTn3zCcIAkfooZMh+mPMcpA8aOO vpIO3/Lq8OL14jbomnJ0Rs1aAPTI5JvYqDLPV7HTpRLsNQZiULMW1RdR6bJ8IGG9Nb5t Q0jigeSIk34nCYtwp1yuooYE8eBLhhC+akacws6b3FHWCdwpb2ZVUv2xcoOoDW2llfXn FtrCq4Oh9Uos16uVB6H74To1NhhG5qhAOggrReirVeM5LHf0FJ3aY+KL7UMVjwI2bruw YPXRF85is0JesrGqtU4WEmWt32ukwd7QWAEkCBUccBobbfnILGOVO5VMTs2ZFJLd7IjK XCnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UaDZMAwmx6Zc/9HvUCVuQHK+naAGMCh1r8otkIRM0ow=; b=MOhR1GTOjXc1FN+DFZY7GV0m3+zR+x29DpNFzrXJk+1o+9Vy/Z/oh2JlE8c/IthpRR nja++qBLSu4DVIpU1uLLeHyUMfQMSn3s2jWMsiBu6D2RdDMFIPoQ2kgSD7cbQ/LFD0U/ PPVdQdHtiFuYMFFV3hUDef9pDBzfxpL4UWHfZnVKkPsPEYeJPDpN+54thZBDRpLUgekC PCbBuhblGguwul0fgAnZamx0tQgftLEThrp9RuUjvkFeu1Fl2u8Bcgh3mZMV2LCQEpAV IXxEDmZ3CZahJ/0a4x18VOukUS04iE4RbjC0G8AxemUKC85e3OibNwcjnJ8r5uoZp4HH 6mHA==
X-Gm-Message-State: APjAAAU6AA9KSonQdzz2Q8JB6qok0bZ4eWoXH3CHsLUczEB1DsLKJmVW AWLlpk9pXRi55RVySWVyM8/CPpNV
X-Google-Smtp-Source: APXvYqzIWDJ/H+BjctZ9HaCONnoYvmb+0DoTKgHc96mWH8beHy14TPWV+veoeOaIB2yNDogPBpK2vQ==
X-Received: by 2002:ac8:36b9:: with SMTP id a54mr46266150qtc.300.1563710092208; Sun, 21 Jul 2019 04:54:52 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id f22sm15358464qkk.45.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jul 2019 04:54:51 -0700 (PDT)
From: Marie-Jose Montpetit <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2351E793-4EDF-4955-91EF-A65164803403"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sun, 21 Jul 2019 07:54:12 -0400
In-Reply-To: <014401d53fac$febb9a10$fc32ce30$>
References: <014401d53fac$febb9a10$fc32ce30$>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [Coin] IPv6 Switch ML @ IETF 105 Hackathon
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "COIN: Computing in the Network" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 21 Jul 2019 11:54:56 -0000

Thanks for this note and yesterday’s participation!


> On Jul 21, 2019, at 6:13 AM, <> <> wrote:
> I ran into interesting issues writing Algorithm 1 from <>  at the hackathon yesterday.  It would be good for any author of the paper to chime in.
> First, I have read several research papers using P4 which publish P4 or pseudo P4 code in the paper.  The switch ML paper does not.  It would have been good to publish the code because P4 is jumping through hoops implementing Algorithm 1 for switch with bmv2 simulator.  I used public-domain p4lang/p4c and its bmv2 simple_switch simulation to test P4 code at the hackathon.
> I used a P4 header stack (array) to represent the vector.  P4 has no for loops, so how does one add elements of the vector? There is the one way.  You can have one action that adds 1 header, another that adds 2, another that adds 3, etc., and choose between them at run time via a table lookup.   Even with a vector with 20-50 elements, writing such P4 code manually is risky.  One has to write a Python script to generate such code.  The paper did not think of it, but an alternative exists.  With every element in the vector, use a new 1-byte field.  The field has values 0 or 1.  1 represents bos (bottom of stack) like what MPLS uses.  The last element has bos set to 1.  Then, one has a termination condition in the P4 parser to terminate recursive parsing of vector.  As the parser is recursing through the vector, add the vector elements and save sum in metadata.  I didn’t use a bit for bos because the p4c bmv2 model accepts a header on byte boundary.  I plan to add such details to my draft in the next revision: <>  
> The same p4c bmv2 model, also, does not accept an index into array if the index is a run-time value.  The p4-16 specification allows run-time index.  Algorithm 1  in the paper uses p.idx which is a run-time value.  Again, one has to use P4 tables.  Include the run-time variable index as a table search key, which selects between several different actions that are identical, except for the constant array index values they use.  This gets crazy with 128 or 512 indices in the paper.  Again, one would have to generate P4 code to avoid mistakes cut-and-pasting code.  For 128 indices with some bit shifting, maybe we reduces indices to 32.   If the Barefoot Tofino asic allows run-time index into array, then it’s better to use Tofino simulator rather than bmv2 simulator.
> I am not working in the hackathon today.  I have personal matters to take care of on Sunday.
> Hemant
> -- 
> Coin mailing list
> <>
> <>