[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BYAPR02MB52382D9342669D4D578C85D8AA7C9@BYAPR02MB5238.namprd02.prod.outlook.com>
Date: Tue, 21 Dec 2021 23:28:20 +0000
From: Tyler Wear <twear@...cinc.com>
To: Martin KaFai Lau <kafai@...com>,
Maciej Żenczykowski <maze@...gle.com>
CC: "Tyler Wear (QUIC)" <quic_twear@...cinc.com>,
Yonghong Song <yhs@...com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>
Subject: RE: [PATCH] Bpf Helper Function BPF_FUNC_skb_change_dsfield
> On Tue, Dec 21, 2021 at 02:13:04PM -0800, Maciej Żenczykowski wrote:
> > > > As for what is driving this? Upcoming wifi standard to allow
> > > > access points to inform client devices how to dscp mark individual flows.
> > > Interesting.
> > >
> > > How does the sending host get this dscp value from wifi and then
> > > affect the dscp of a particular flow? Is the dscp going to be
> > > stored in a bpf map for the bpf prog to use?
> >
> > It gets it out of band via some wifi signaling mechanism.
> > Tyler probably knows the details.
> >
> > Storing flow match information to dscp mapping in a bpf map is indeed the plan.
> >
This is for an upcoming QoS Wifi Alliance spec. Wifi will get the dscp for a corresponding
flow and as Maze said the current plan is to store this map info in bpf to modify packets.
Powered by blists - more mailing lists