---------- Forwarded message --------- From: Jamal Hadi Salim <j...@mojatatu.com> Date: Fri, Jan 27, 2023 at 6:00 AM Subject: Re: [PATCH net-next RFC 00/20] Introducing P4TC To: Jakub Kicinski <k...@kernel.org> Cc: <net...@vger.kernel.org>, <ker...@mojatatu.com>, <deb.chatter...@intel.com>, <anjali.sing...@intel.com>, <namrata.lim...@intel.com>, <khal...@nvidia.com>, <t...@sipanda.io>, <praty...@sipanda.io>, <j...@resnulli.us>, <xiyou.wangc...@gmail.com>, <da...@davemloft.net>, <eduma...@google.com>, <pab...@redhat.com>, <vla...@nvidia.com>, <simon.hor...@corigine.com>, <stef...@marvell.com>, <seong....@amd.com>, <mat...@nvidia.com>, <dan.d...@intel.com>, <john.andy.finger...@intel.com>
On Thu, Jan 26, 2023 at 6:30 PM Jakub Kicinski <k...@kernel.org> wrote: > > On Tue, 24 Jan 2023 12:03:46 -0500 Jamal Hadi Salim wrote: > > There have been many discussions and meetings since about 2015 in regards to > > P4 over TC and now that the market has chosen P4 as the datapath > > specification > > lingua franca > > Which market? Network programmability involving hardware - where at minimal the specification of the datapath is in P4 and often the implementation is. For samples of specification using P4 (that are public) see for example MS Azure: https://github.com/sonic-net/DASH/tree/main/dash-pipeline If you are a vendor and want to sell a NIC in that space, the spec you get is in P4. Your underlying hardware doesnt have to be P4 native, but at minimal the abstraction (as we are trying to provide with P4TC) has to be able to consume the P4 specification. For implementations where P4 is in use, there are many - some public others not, sample space: https://cloud.google.com/blog/products/gcp/google-cloud-using-p4runtime-to-build-smart-networks There are NICs and switches which are P4 native in the market. IOW, there is beacoup $ investment in this space that makes it worth pursuing. TC is the kernel offload mechanism that has gathered deployment experience over many years - hence P4TC. > Barely anyone understands the existing TC offloads. Hyperboles like these are never helpful in a discussion. TC offloads are deployed today, they work and many folks are actively working on them. Are there challenges? yes. For one (and this applies to all kernel offloads) the process gets in the way of exposing new features. So there are learnings that we try to resolve in P4TC. I'd be curious to hear about your suffering with TC offloads and see if we can take that experience and make things better. >We'd need strong, > and practical reasons to merge this. Speaking with my "have suffered > thru the TC offloads working for a vendor" hat on, not the "junior > maintainer" hat. P4TC is "standalone" in that it does not affect other TC consumers or any other subsystems on performance; it is also sufficiently isolated in that you can choose to compile it out altogether and more importantly it comes with committed support. And i should emphasize this discussion on getting P4 on TC has been going on for a few years in the community culminating with this. cheers, jamal -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz Dave Täht CEO, TekLibre, LLC _______________________________________________ LibreQoS mailing list LibreQoS@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/libreqos
