From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by dpdk.org (Postfix) with ESMTP id 2F4C81B29B for ; Thu, 21 Dec 2017 15:51:07 +0100 (CET) Received: by mail-io0-f182.google.com with SMTP id f7so886489ioh.1 for ; Thu, 21 Dec 2017 06:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1Xfv94wX7E8auWPHVU6e7xASmmuKdbR3XoKIawk3P1Y=; b=VPHpJ+4NWCE/PU/9yoXqlofYpUXHZ8CJo1l0uvSpRmcyfXWL8JralmbViPD+EYVdAh gieBBTwgaC4W+idWRccg6GF20quvQr0we7vNevgZfzFEJcVxnbyqQX3EMLUNQxJE+xaI 8S+0ivvaqeQ/iDa1r803hm0Iv9PFhMmxeZxiQvlkVYTZ9G/NYz9WHxpJOrXqcz/TmYzB 8yGgFlVb5tniO5DDIN6pDVIUFO5o8cHXG0SFCtIpZFlLQ4n0fN3tfb8TwCtXbpwIhBly I07RQxiPHNIV+375MSJPJrfrNm0CQdYs0WOjA+xpBVaM+X9GpaIf4enw68AC91fyvtlD jG3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1Xfv94wX7E8auWPHVU6e7xASmmuKdbR3XoKIawk3P1Y=; b=tHOVE9zCjg058Xe7iyqv1JYBhtUib8gnI98tTIC387NS3SkIbxkHPM2qbSCbNKDtGc 5MqbmAInElFVmJdt9oavWAEFsgeCmfFB+yN+gzRRAo4q+5cnZKCrI9ML42HuwmyBL7hm h3m6j6vz1YO6ObZQOuBTZIZWGFPbi7V0JAx/zIYmYN9B0eejpEqNVyizeGolI4Fmef9h t2QHwovMe57Zi1oVrAGiT2KEjKbvRtV085OzqsFSC7guhQ8TbQuWx7beNUBfLIgw6bAs LntCf754d+s4EL9R4EMFfB9eLe3LBHNkv6lxtT/6TxHLeeaP7d3VRVdnmDFIZuuu+Ojg oPlg== X-Gm-Message-State: AKGB3mKGRj86fQQa/00mm8gMU3GSWxRIXCO+aU5p/A7da1jFCtb4UodK CjuYdidiqyuLYjPOJp06ZQBGBBaTcNp30yVzLo0= X-Google-Smtp-Source: ACJfBotytgFfiP5iMZz0NuMT5aPGfWFxea5elRzhRI/6KI1+WwSztPVQh+xBJ13DjwDc3TsgeauaRwAy9IfSS5CPjL0= X-Received: by 10.107.102.24 with SMTP id a24mr12066623ioc.144.1513867866404; Thu, 21 Dec 2017 06:51:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.53.2 with HTTP; Thu, 21 Dec 2017 06:51:05 -0800 (PST) In-Reply-To: References: <1504773339-21022-1-git-send-email-mohammad.abdul.awal@intel.com> From: Alex Rosenbaum Date: Thu, 21 Dec 2017 16:51:05 +0200 Message-ID: To: Declan Doherty , Mohammad Abdul Awal Cc: dev , Remy Horton , Rony Efraim , Alejandro Lucero Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC 0/5] Port Representor for control and monitoring of VF devices X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 14:51:07 -0000 Declan, Mohammad, The submission [1] of steering action between switch ports clearly requires a switch model in DPDK. The Port Representor based on a virtual PMD broker on NIC ops (rte_dev_ops) does not provide the required functionality. Using NIC terminology and not Switch API's will lead to a dead-end. Moreover, it does not fit the Kernel design. We need to be careful from this ending up as two different deployment models for users, which is very bad. There was a long discussion about this in netdev ML [2], including the VEPA mode support. As described in the links Alejandro referenced earlier, each of the switch ports should be a real PMD, and switch operations should be applied on these PMD ports. This includes the steering redirection of traffic between switch ports [1], port ACL's to block/allow traffic, VST/VGT modes and anti spoofing, link trust mode [3] for promiscuous configuration, mirroring of switch port traffic, and Tx and Rx of switch port traffic to/from VF's port. More over, building this as real PMD ports of a switch device removes the need to add a new broker framework all together. Each vendor just needs to map additional PMD ports during the probing stage. By adding a switchdev_id we can define these are ports associated to the same switching device, and can allow new port and inter-port actions. [1] http://dpdk.org/dev/patchwork/patch/32550/ [2] https://www.spinics.net/lists/netdev/msg467375.html [2] https://www.systutorials.com/docs/linux/man/8-ip-link/ Alex