From: Xu Yilun <yilun.xu@intel.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
jesse.brandeburg@intel.com, anthony.l.nguyen@intel.com,
davem@davemloft.net, mdf@kernel.org, lee.jones@linaro.org,
linux-kernel@vger.kernel.org, linux-fpga@vger.kernel.org,
netdev@vger.kernel.org, trix@redhat.com, lgoncalv@redhat.com,
hao.wu@intel.com, yilun.xu@intel.com
Subject: Re: [RFC PATCH 1/6] docs: networking: add the document for DFL Ether Group driver
Date: Tue, 27 Oct 2020 10:33:41 +0800 [thread overview]
Message-ID: <20201027023341.GB10743@yilunxu-OptiPlex-7050> (raw)
In-Reply-To: <20201026113552.78e7a2b4@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
On Mon, Oct 26, 2020 at 11:35:52AM -0700, Jakub Kicinski wrote:
> On Tue, 27 Oct 2020 01:38:04 +0800 Xu Yilun wrote:
> > > > The line/host side Ether Group is not the terminal of the network data stream.
> > > > Eth1 will not paticipate in the network data exchange to host.
> > > >
> > > > The main purposes for eth1 are:
> > > > 1. For users to monitor the network statistics on Line Side, and by comparing the
> > > > statistics between eth0 & eth1, users could get some knowledge of how the User
> > > > logic is taking function.
> > > >
> > > > 2. Get the link state of the front panel. The XL710 is now connected to
> > > > Host Side of the FPGA and the its link state would be always on. So to
> > > > check the link state of the front panel, we need to query eth1.
> > >
> > > This is very non-intuitive. We try to avoid this in the kernel and the
> > > API to userspace. Ethernet switches are always modelled as
> > > accelerators for what the Linux network stack can already do. You
> > > configure an Ethernet switch port in just the same way configure any
> > > other netdev. You add an IP address to the switch port, you get the
> > > Ethernet statistics from the switch port, routing protocols use the
> > > switch port.
> > >
> > > You design needs to be the same. All configuration needs to happen via
> > > eth1.
> > >
> > > Please look at the DSA architecture. What you have here is very
> > > similar to a two port DSA switch. In DSA terminology, we would call
> > > eth0 the master interface. It needs to be up, but otherwise the user
> > > does not configure it. eth1 is the slave interface. It is the user
> > > facing interface of the switch. All configuration happens on this
> > > interface. Linux can also send/receive packets on this netdev. The
> > > slave TX function forwards the frame to the master interface netdev,
> > > via a DSA tagger. Frames which eth0 receive are passed through the
> > > tagger and then passed to the slave interface.
> > >
> > > All the infrastructure you need is already in place. Please use
> > > it. I'm not saying you need to write a DSA driver, but you should make
> > > use of the same ideas and low level hooks in the network stack which
> > > DSA uses.
> >
> > I did some investigation about the DSA, and actually I wrote a
> > experimental DSA driver. It works and almost meets my need, I can make
> > configuration, run pktgen on slave inf.
> >
> > A main concern for dsa is the wiring from slave inf to master inf depends
> > on the user logic. If FPGA users want to make their own user logic, they
> > may need a new driver. But our original design for the FPGA is, kernel
> > drivers support the fundamental parts - FPGA FIU (where Ether Group is in)
> > & other peripherals on board, and userspace direct I/O access for User
> > logic. Then FPGA user don't have to write & compile a driver for their
> > user logic change.
> > It seems not that case for netdev. The user logic is a part of the whole
> > functionality of the netdev, we cannot split part of the hardware
> > component to userspace and the rest in kernel. I really need to
> > reconsider this.
>
> This is obviously on purpose. Your design as it stands will not fly
> upstream, sorry.
>
> >From netdev perspective the user should not care how many hardware
> blocks are in the pipeline, and on which piece of silicon. You have
> a 2 port (modulo port splitting) card, there should be 2 netdevs, and
> the link config and forwarding should be configured through those.
>
> Please let folks at Intel know that we don't like the "SDK in user
> space with reuse [/abuse] of parts of netdev infra" architecture.
> This is a second of those we see in a short time. Kernel is not a
> library for your SDK to use.
I get your point. I'll share the information internally and reconsider
the design.
Thanks,
Yilun
next prev parent reply other threads:[~2020-10-27 2:39 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 8:45 [RFC PATCH 0/6] Add the netdev support for Intel PAC N3000 FPGA Xu Yilun
2020-10-23 8:45 ` [RFC PATCH 1/6] docs: networking: add the document for DFL Ether Group driver Xu Yilun
2020-10-23 15:37 ` Andrew Lunn
2020-10-26 8:52 ` Xu Yilun
2020-10-26 13:00 ` Andrew Lunn
2020-10-26 17:38 ` Xu Yilun
2020-10-26 18:35 ` Jakub Kicinski
2020-10-27 2:33 ` Xu Yilun [this message]
2020-10-26 19:14 ` Andrew Lunn
2020-10-27 3:27 ` Xu Yilun
2020-11-02 2:38 ` Xu Yilun
2020-11-02 14:46 ` Andrew Lunn
2020-10-24 14:25 ` Tom Rix
2020-10-23 8:45 ` [RFC PATCH 2/6] fpga: dfl: export network configuration info for DFL based FPGA Xu Yilun
2020-10-24 13:59 ` Tom Rix
2020-10-26 3:29 ` Wu, Hao
2020-10-23 8:45 ` [RFC PATCH 3/6] fpga: dfl: add an API to get the base device for dfl device Xu Yilun
2020-10-24 14:39 ` Tom Rix
2020-10-26 3:42 ` Wu, Hao
2020-10-23 8:45 ` [RFC PATCH 4/6] ethernet: m10-retimer: add support for retimers on Intel MAX 10 BMC Xu Yilun
2020-10-24 15:03 ` Tom Rix
2020-10-24 16:39 ` Andrew Lunn
2020-10-24 17:36 ` Tom Rix
2020-10-24 20:33 ` Andrew Lunn
2020-10-23 8:45 ` [RFC PATCH 5/6] ethernet: dfl-eth-group: add DFL eth group private feature driver Xu Yilun
2020-10-24 14:37 ` Andrew Lunn
2020-10-24 17:25 ` Tom Rix
2020-10-25 14:47 ` Andrew Lunn
2020-10-23 8:45 ` [RFC PATCH 6/6] ethernet: dfl-eth-group: add support for the 10G configurations Xu Yilun
2020-10-24 17:43 ` Tom Rix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201027023341.GB10743@yilunxu-OptiPlex-7050 \
--to=yilun.xu@intel.com \
--cc=andrew@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=hao.wu@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=kuba@kernel.org \
--cc=lee.jones@linaro.org \
--cc=lgoncalv@redhat.com \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mdf@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=trix@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).