On Fri, Jul 06, 2018 at 06:44:24PM -0700, Jakub Kicinski wrote:
> On Fri, 6 Jul 2018 17:53:18 -0700, Alexei Starovoitov wrote:
> > On Fri, Jul 06, 2018 at 05:08:47PM -0700, Jakub Kicinski wrote:
> > > On Fri, 6 Jul 2018 16:42:51 -0700, Alexei Starovoitov wrote:
> > > > On Fri, Jul 06, 2018 at 02:
On Fri, Jul 06, 2018 at 06:20:47PM -0700, Jakub Kicinski wrote:
> On Fri, 6 Jul 2018 18:00:13 -0700, Alexei Starovoitov wrote:
> > On Fri, Jul 06, 2018 at 05:40:43PM -0700, Jakub Kicinski wrote:
> > >
> > > Could we just say that at the start we expose only existing SKB fields
> > > (csum, hash, m
On Fri, 6 Jul 2018 17:53:18 -0700, Alexei Starovoitov wrote:
> On Fri, Jul 06, 2018 at 05:08:47PM -0700, Jakub Kicinski wrote:
> > On Fri, 6 Jul 2018 16:42:51 -0700, Alexei Starovoitov wrote:
> > > On Fri, Jul 06, 2018 at 02:33:58PM -0700, Jakub Kicinski wrote:
> > > > On Fri, 6 Jul 2018 09:30:
From: Alexei Starovoitov
Date: Fri, 6 Jul 2018 17:53:18 -0700
> I'd like to push back on firmware folks that should be listening
> to feedback from driver folks and kernel stack instead of saying
> 'here is hw spec that firmware provides'. Firmware is software.
> It can change and should be open
From: Alexei Starovoitov
Date: Fri, 6 Jul 2018 09:30:42 -0700
> Like doing offset rewriting at program load time similar to what we plan
> to do for tracing. Tracing programs will be doing 'task->pid' access
> and the kernel will adjust offsetof(struct task_struct, pid) during program
> load
> d
On Fri, 6 Jul 2018 18:00:13 -0700, Alexei Starovoitov wrote:
> On Fri, Jul 06, 2018 at 05:40:43PM -0700, Jakub Kicinski wrote:
> >
> > Could we just say that at the start we expose only existing SKB fields
> > (csum, hash, mark) and the meaning of the is the same as in the SKB?
>
> what would b
On Fri, Jul 06, 2018 at 05:40:43PM -0700, Jakub Kicinski wrote:
>
> Could we just say that at the start we expose only existing SKB fields
> (csum, hash, mark) and the meaning of the is the same as in the SKB?
what would be the meaning of 'hash' ? Over which fields?
Does it support inner and oute
On Fri, Jul 06, 2018 at 05:08:47PM -0700, Jakub Kicinski wrote:
> On Fri, 6 Jul 2018 16:42:51 -0700, Alexei Starovoitov wrote:
> > On Fri, Jul 06, 2018 at 02:33:58PM -0700, Jakub Kicinski wrote:
> > > On Fri, 6 Jul 2018 09:30:42 -0700, Alexei Starovoitov wrote:
> > > > On Thu, Jul 05, 2018 at 10:
On Fri, Jul 06, 2018 at 11:49:55PM +, Waskiewicz Jr, Peter wrote:
> On Fri, 2018-07-06 at 16:38 -0700, Alexei Starovoitov wrote:
> > On Fri, Jul 06, 2018 at 08:44:24PM +, Waskiewicz Jr, Peter wrote:
> > > On Fri, 2018-07-06 at 09:30 -0700, Alexei Starovoitov wrote:
> > > > On Thu, Jul 05, 2
On Fri, 6 Jul 2018 23:49:55 +, Waskiewicz Jr, Peter wrote:
> On Fri, 2018-07-06 at 16:38 -0700, Alexei Starovoitov wrote:
> > On Fri, Jul 06, 2018 at 08:44:24PM +, Waskiewicz Jr, Peter wrote:
> > > On Fri, 2018-07-06 at 09:30 -0700, Alexei Starovoitov wrote:
> > > > On Thu, Jul 05, 2018
On Fri, 6 Jul 2018 16:42:51 -0700, Alexei Starovoitov wrote:
> On Fri, Jul 06, 2018 at 02:33:58PM -0700, Jakub Kicinski wrote:
> > On Fri, 6 Jul 2018 09:30:42 -0700, Alexei Starovoitov wrote:
> > > On Thu, Jul 05, 2018 at 10:18:23AM -0700, Jakub Kicinski wrote:
> > > >
> > > > I'm also not 100
On Fri, 2018-07-06 at 16:38 -0700, Alexei Starovoitov wrote:
> On Fri, Jul 06, 2018 at 08:44:24PM +, Waskiewicz Jr, Peter wrote:
> > On Fri, 2018-07-06 at 09:30 -0700, Alexei Starovoitov wrote:
> > > On Thu, Jul 05, 2018 at 10:18:23AM -0700, Jakub Kicinski wrote:
> > > >
> > > > I'm also not 1
On Fri, Jul 06, 2018 at 02:33:58PM -0700, Jakub Kicinski wrote:
> On Fri, 6 Jul 2018 09:30:42 -0700, Alexei Starovoitov wrote:
> > On Thu, Jul 05, 2018 at 10:18:23AM -0700, Jakub Kicinski wrote:
> > >
> > > I'm also not 100% on board with the argument that "future" FW can
> > > reshuffle things wh
On Fri, Jul 06, 2018 at 08:44:24PM +, Waskiewicz Jr, Peter wrote:
> On Fri, 2018-07-06 at 09:30 -0700, Alexei Starovoitov wrote:
> > On Thu, Jul 05, 2018 at 10:18:23AM -0700, Jakub Kicinski wrote:
> > >
> > > I'm also not 100% on board with the argument that "future" FW can
> > > reshuffle thi
On Fri, 6 Jul 2018 09:30:42 -0700, Alexei Starovoitov wrote:
> On Thu, Jul 05, 2018 at 10:18:23AM -0700, Jakub Kicinski wrote:
> >
> > I'm also not 100% on board with the argument that "future" FW can
> > reshuffle things whatever way it wants to. Is the assumption that
> > future ASICs/FW will b
On Fri, 2018-07-06 at 09:30 -0700, Alexei Starovoitov wrote:
> On Thu, Jul 05, 2018 at 10:18:23AM -0700, Jakub Kicinski wrote:
> >
> > I'm also not 100% on board with the argument that "future" FW can
> > reshuffle things whatever way it wants to. Is the assumption that
> > future ASICs/FW will b
On Thu, Jul 05, 2018 at 10:18:23AM -0700, Jakub Kicinski wrote:
>
> I'm also not 100% on board with the argument that "future" FW can
> reshuffle things whatever way it wants to. Is the assumption that
> future ASICs/FW will be designed to always use the "blessed" BTF
> format? Or will it be rec
On Wed, 4 Jul 2018 09:51:54 +0200, Daniel Borkmann wrote:
> On 07/04/2018 02:57 AM, Saeed Mahameed wrote:
> > On Tue, 2018-07-03 at 16:01 -0700, Alexei Starovoitov wrote:
> >> How about we make driver+firmware provide a BTF definition of
> >> metadata that they
> >> can provide? There can be mult
On 07/04/2018 02:57 AM, Saeed Mahameed wrote:
> On Tue, 2018-07-03 at 16:01 -0700, Alexei Starovoitov wrote:
[...]
>> How about we make driver+firmware provide a BTF definition of
>> metadata that they
>> can provide? There can be multiple definitions of such structs.
>> Then in userpsace we can ha
On Tue, 2018-07-03 at 16:01 -0700, Alexei Starovoitov wrote:
> On Tue, Jun 26, 2018 at 07:46:11PM -0700, Saeed Mahameed wrote:
> > The idea from this patch is to define a well known structure for
> > XDP meta
> > data fields format and offset placement inside the xdp data meta
> > buffer.
> >
> >
On Mon, 2018-07-02 at 10:01 +0200, Daniel Borkmann wrote:
> On 06/27/2018 07:55 PM, Saeed Mahameed wrote:
> > On Wed, 2018-06-27 at 16:15 +0200, Jesper Dangaard Brouer wrote:
> > > On Tue, 26 Jun 2018 19:46:11 -0700
> > > Saeed Mahameed wrote:
> > >
> > > > diff --git a/include/net/xdp.h b/includ
On Tue, Jun 26, 2018 at 07:46:11PM -0700, Saeed Mahameed wrote:
> The idea from this patch is to define a well known structure for XDP meta
> data fields format and offset placement inside the xdp data meta buffer.
>
> For that driver will need some static information to know what to
> provide and
On 06/27/2018 07:55 PM, Saeed Mahameed wrote:
> On Wed, 2018-06-27 at 16:15 +0200, Jesper Dangaard Brouer wrote:
>> On Tue, 26 Jun 2018 19:46:11 -0700
>> Saeed Mahameed wrote:
>>
>>> diff --git a/include/net/xdp.h b/include/net/xdp.h
>>> index 2deea7166a34..afe302613ae1 100644
>>> --- a/include/ne
On Wed, 2018-06-27 at 16:15 +0200, Jesper Dangaard Brouer wrote:
> On Tue, 26 Jun 2018 19:46:11 -0700
> Saeed Mahameed wrote:
>
> > diff --git a/include/net/xdp.h b/include/net/xdp.h
> > index 2deea7166a34..afe302613ae1 100644
> > --- a/include/net/xdp.h
> > +++ b/include/net/xdp.h
> > @@ -138,6
On Tue, 26 Jun 2018 19:46:11 -0700
Saeed Mahameed wrote:
> diff --git a/include/net/xdp.h b/include/net/xdp.h
> index 2deea7166a34..afe302613ae1 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -138,6 +138,12 @@ xdp_set_data_meta_invalid(struct xdp_buff *xdp)
> xdp->data_meta
The idea from this patch is to define a well known structure for XDP meta
data fields format and offset placement inside the xdp data meta buffer.
For that driver will need some static information to know what to
provide and where, enters struct xdp_md_info and xdp_md_info_arr:
struct xdp_md_info
26 matches
Mail list logo
