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

<hemant@mnkcg.com> Sat, 25 January 2020 00:44 UTC

Return-Path: <hemant@mnkcg.com>
X-Original-To: coin@ietfa.amsl.com
Delivered-To: coin@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D815E1200D8 for <coin@ietfa.amsl.com>; Fri, 24 Jan 2020 16:44:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnkcg.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBv2JbD4RMA0 for <coin@ietfa.amsl.com>; Fri, 24 Jan 2020 16:44:20 -0800 (PST)
Received: from web143.dnchosting.com (web143.dnchosting.com [104.171.28.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D608612001B for <coin@irtf.org>; Fri, 24 Jan 2020 16:44:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mnkcg.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cV1o4uybMwk51+TwH1oj2fjdxCCPNj/Q7Fhhu10XUqU=; b=rIBMQmL32GxPdb6449tuIwzCpY V6FauAEdqMhim8tHIXpWXT0q79MYBQVaULJSQhIwjOJtNPI0zJUz5A15XaU/3pbdMD8TgYwDGDrHK apE9oz8Ihox90EuehbzRZuGcuTfqaItfDwPFDx+UNunpiqae4Yth7e8MzkcmRSsM4pJIOOcRQRYny QSjlhbDpC7MDwqywc2AzKmH92sqKO5d99BdehLvRHzV+0am/JVr78bF8FyfbRX+Y5D5/tt+/OWODd m1aB8SNvKgMwTMxeWFr+HDmj2jfK1hW9A+e+t48EQ0iv62KsoZC2RbMC4tvVh1Ll1qbmNsv8f+wu8 nd7bwZTg==;
Received: from pool-173-76-164-153.bstnma.fios.verizon.net ([173.76.164.153]:55478 helo=hemantPC) by web143.dnchosting.com with esmtpa (Exim 4.92) (envelope-from <hemant@mnkcg.com>) id 1iv9YX-00AETk-UZ for coin@irtf.org; Fri, 24 Jan 2020 19:44:20 -0500
From: hemant@mnkcg.com
To: coin@irtf.org
References: <014401d53fac$febb9a10$fc32ce30$@mnkcg.com> <046101d5d317$bfbf1fe0$3f3d5fa0$@mnkcg.com>
In-Reply-To: <046101d5d317$bfbf1fe0$3f3d5fa0$@mnkcg.com>
Date: Fri, 24 Jan 2020 19:44:23 -0500
Message-ID: <047f01d5d318$972a5f30$c57f1d90$@mnkcg.com>
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIyIv4AW2hx8wpvnn6DlsY7G+t1/AG54RAkpzQb6uA=
MIME-Version: 1.0
Content-Language: en-us
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0477_01D5D2EE.ADD38E70"
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web143.dnchosting.com
X-AntiAbuse: Original Domain - irtf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - mnkcg.com
X-Get-Message-Sender-Via: web143.dnchosting.com: authenticated_id: hemant@mnkcg.com
X-Authenticated-Sender: web143.dnchosting.com: hemant@mnkcg.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/HDzfuoTwpuKfL4W6rmS-VyKZpQM>
Subject: [Coin] FW: IPv6 Switch ML @ IETF 105 Hackathon
X-BeenThere: coin@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "COIN: Computing in the Network" <coin.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/coin>, <mailto:coin-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/coin/>
List-Post: <mailto:coin@irtf.org>
List-Help: <mailto:coin-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/coin>, <mailto:coin-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jan 2020 00:44:24 -0000

This email bounced back.  Trying one more time.

 

Sorry for any spam.

 

Hemant

 

From: hemant@mnkcg.com <hemant@mnkcg.com> 
Sent: Friday, January 24, 2020 7:38 PM
To: hemant@mnkcg.com; coin@irtf.org
Subject: RE: [Coin] IPv6 Switch ML @ IETF 105 Hackathon

 

An update:

 

The second problem listed in the email below, viz., runtime index of array,
is solved.

 

The open-source P4 compiler (p4lang/p4c) and simple_switch simulator
(p4lang/behavioral-model) were changed to support runtime index for an
array.  I changed p4c and Antonin Bas changed the simple_switch.   I expect
to check in code to p4c early next week.  Simple_switch code is already
checked in. 

 

The software can be added to a FPGA.  Then switch-ML could run on smartNIC
using a FPGA.  Just add a home hub or switch to the smartNIC port and one
has at least 8-10 hosts running switch-ML with the smartNIC.  Now, a
graduate student can write switch-ML code. 

 

No switching or routing asic supports a runtime index for an array.  It's
now up to asic vendors to support the feature.

 

For the Vancouver IETF, I don't see why we can't complete the switch-ML
P4-16 software and use the simple_switch and mininet hosts to run switch-ML.
Unfortunately, I am busy with other compiler work, so others can just use
runtime index and the parser trick included below and develop the P4 code.

 

We try and write production quality code for the P4 compiler.  Here are some
examples of runtime array indices tested with new code.

 

hdr.vector[hdr.ml.idx1 - (hdr.ml.idx2 >> 8w1)].e =
hdr.ethernet.etherType[15:8] + 7;

hdr.ethernet.etherType[7:0] = hdr.vector[(hdr.ml.idx2 ^ 8w0x07) & 8w0x7].e;

hdr.vector[hdr.vector[hdr.ethernet.dstAddr[39:32] & 8w0x7].e & 8w0x7].e =
hdr.ethernet.dstAddr[47:40];

 

If the runtime index exceeds array bounds, the simulator will crash. 

 

Hemant

 

From: Coin <coin-bounces@irtf.org <mailto:coin-bounces@irtf.org> > On Behalf
Of hemant@mnkcg.com <mailto:hemant@mnkcg.com> 
Sent: Sunday, July 21, 2019 6:14 AM
To: coin@irtf.org <mailto:coin@irtf.org> 
Subject: [Coin] IPv6 Switch ML @ IETF 105 Hackathon

 

I ran into interesting issues writing Algorithm 1 from
https://arxiv.org/pdf/1903.06701.pdf  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:
https://datatracker.ietf.org/doc/html/draft-hsingh-ipv6-coin-ml  

 

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