On Tue, Apr 05, 2016 at 05:15:20PM +0300, Or Gerlitz wrote:
> On 4/4/2016 9:50 PM, Alexei Starovoitov wrote:
> >On Mon, Apr 04, 2016 at 08:22:03AM -0700, Eric Dumazet wrote:
> >>A single flow is able to use 40Gbit on those 40Gbit NIC, so there is not
> >>a single 10GB trunk used for a given flow.
>
On Tue, Apr 5, 2016 at 5:20 AM, Brenden Blanco wrote:
> On Sat, Apr 02, 2016 at 11:15:38PM -0700, Brenden Blanco wrote:
>> On Fri, Apr 01, 2016 at 07:08:31PM -0700, Eric Dumazet wrote:
> [...]
>> > 2) priv->stats.rx_dropped is shared by all the RX queues -> false
>> > sharing.
>> >
>> >This is
On 4/4/2016 9:50 PM, Alexei Starovoitov wrote:
On Mon, Apr 04, 2016 at 08:22:03AM -0700, Eric Dumazet wrote:
A single flow is able to use 40Gbit on those 40Gbit NIC, so there is not
a single 10GB trunk used for a given flow.
This 14Mpps thing seems to be a queue limitation on mlx4.
yeah, could
On Mon, 4 Apr 2016 11:27:27 -0700
Alexei Starovoitov wrote:
> On Sat, Apr 02, 2016 at 11:11:52PM -0700, Brenden Blanco wrote:
> > On Sat, Apr 02, 2016 at 10:23:31AM +0200, Jesper Dangaard Brouer wrote:
> > [...]
> > >
> > > I think you need to DMA sync RX-page before you can safely access
> >
On Mon, 2016-04-04 at 19:20 -0700, Brenden Blanco wrote:
> On Sat, Apr 02, 2016 at 11:15:38PM -0700, Brenden Blanco wrote:
> > On Fri, Apr 01, 2016 at 07:08:31PM -0700, Eric Dumazet wrote:
> [...]
> > > 2) priv->stats.rx_dropped is shared by all the RX queues -> false
> > > sharing.
> > >
> > >
On Sat, Apr 02, 2016 at 11:15:38PM -0700, Brenden Blanco wrote:
> On Fri, Apr 01, 2016 at 07:08:31PM -0700, Eric Dumazet wrote:
[...]
> > 2) priv->stats.rx_dropped is shared by all the RX queues -> false
> > sharing.
> >
> >This is probably the right time to add a rx_dropped field in struct
>
On Mon, Apr 04, 2016 at 11:01:57PM +0200, Daniel Borkmann wrote:
> On 04/04/2016 08:46 PM, Alexei Starovoitov wrote:
> >On Mon, Apr 04, 2016 at 11:57:52AM +0200, Daniel Borkmann wrote:
> >>On 04/04/2016 09:35 AM, Johannes Berg wrote:
> >>>On Sat, 2016-04-02 at 23:38 -0700, Brenden Blanco wrote:
> >
On 04/04/2016 08:46 PM, Alexei Starovoitov wrote:
On Mon, Apr 04, 2016 at 11:57:52AM +0200, Daniel Borkmann wrote:
On 04/04/2016 09:35 AM, Johannes Berg wrote:
On Sat, 2016-04-02 at 23:38 -0700, Brenden Blanco wrote:
Having a common check makes sense. The tricky thing is that the type can
onl
On Mon, Apr 04, 2016 at 08:22:03AM -0700, Eric Dumazet wrote:
> On Mon, 2016-04-04 at 16:57 +0200, Jesper Dangaard Brouer wrote:
> > On Fri, 1 Apr 2016 19:47:12 -0700 Alexei Starovoitov
> > wrote:
> >
> > > My guess we're hitting 14.5Mpps limit for empty bpf program
> > > and for program that ac
On Mon, Apr 04, 2016 at 11:57:52AM +0200, Daniel Borkmann wrote:
> On 04/04/2016 09:35 AM, Johannes Berg wrote:
> >On Sat, 2016-04-02 at 23:38 -0700, Brenden Blanco wrote:
> >>
> >>Having a common check makes sense. The tricky thing is that the type can
> >>only be checked after taking the referenc
On Sat, Apr 02, 2016 at 11:11:52PM -0700, Brenden Blanco wrote:
> On Sat, Apr 02, 2016 at 10:23:31AM +0200, Jesper Dangaard Brouer wrote:
> [...]
> >
> > I think you need to DMA sync RX-page before you can safely access
> > packet data in page (on all arch's).
> >
> Thanks, I will give that a try
On Mon, 2016-04-04 at 16:57 +0200, Jesper Dangaard Brouer wrote:
> On Fri, 1 Apr 2016 19:47:12 -0700 Alexei Starovoitov
> wrote:
>
> > My guess we're hitting 14.5Mpps limit for empty bpf program
> > and for program that actually looks into the packet because we're
> > hitting 10G phy limit of 40
On Fri, 1 Apr 2016 19:47:12 -0700 Alexei Starovoitov
wrote:
> My guess we're hitting 14.5Mpps limit for empty bpf program
> and for program that actually looks into the packet because we're
> hitting 10G phy limit of 40G nic. Since physically 40G nic
> consists of four 10G phys. There will be t
On 04/04/2016 09:35 AM, Johannes Berg wrote:
On Sat, 2016-04-02 at 23:38 -0700, Brenden Blanco wrote:
Having a common check makes sense. The tricky thing is that the type can
only be checked after taking the reference, and I wanted to keep the
scope of the prog brief in the case of errors. I wo
On 04/02/2016 03:21 AM, Brenden Blanco wrote:
Add support for the BPF_PROG_TYPE_PHYS_DEV hook in mlx4 driver. Since
bpf programs require a skb context to navigate the packet, build a
percpu fake skb with the minimal fields. This avoids the costly
allocation for packets that end up being dropped.
On Fri, 1 Apr 2016 18:21:57 -0700
Brenden Blanco wrote:
> @@ -840,6 +843,21 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct
> mlx4_en_cq *cq, int bud
> l2_tunnel = (dev->hw_enc_features & NETIF_F_RXCSUM) &&
> (cqe->vlan_my_qpn & cpu_to_be32(MLX4_C
On Sat, 2016-04-02 at 23:38 -0700, Brenden Blanco wrote:
>
> Having a common check makes sense. The tricky thing is that the type can
> only be checked after taking the reference, and I wanted to keep the
> scope of the prog brief in the case of errors. I would have to move the
> bpf_prog_get logi
On Sat, Apr 02, 2016 at 08:40:55PM +0200, Johannes Berg wrote:
> On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote:
>
> > +static int mlx4_bpf_set(struct net_device *dev, int fd)
> > +{
> [...]
> > + if (prog->type != BPF_PROG_TYPE_PHYS_DEV) {
> > + bpf_prog_put(p
On Fri, Apr 01, 2016 at 07:08:31PM -0700, Eric Dumazet wrote:
[...]
>
>
> 1) mlx4 can use multiple fragments (priv->num_frags) to hold an Ethernet
> frame.
>
> Still you pass a single fragment but total 'length' here : BPF program
> can read past the end of this first fragment and panic the box
On Sat, Apr 02, 2016 at 10:23:31AM +0200, Jesper Dangaard Brouer wrote:
[...]
>
> I think you need to DMA sync RX-page before you can safely access
> packet data in page (on all arch's).
>
Thanks, I will give that a try in the next spin.
> > + ethh = (struct ethhdr *)(page_addre
On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote:
> +static int mlx4_bpf_set(struct net_device *dev, int fd)
> +{
[...]
> + if (prog->type != BPF_PROG_TYPE_PHYS_DEV) {
> + bpf_prog_put(prog);
> + return -EINVAL;
> + }
> + }
First of all, I'm very happy to see people start working on this!
Thanks you Brenden!
On Fri, 1 Apr 2016 18:21:57 -0700
Brenden Blanco wrote:
> Add support for the BPF_PROG_TYPE_PHYS_DEV hook in mlx4 driver. Since
> bpf programs require a skb context to navigate the packet, build a
> percpu f
On Fri, Apr 01, 2016 at 07:08:31PM -0700, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote:
> > Add support for the BPF_PROG_TYPE_PHYS_DEV hook in mlx4 driver. Since
> > bpf programs require a skb context to navigate the packet, build a
> > percpu fake skb with the min
On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote:
> Add support for the BPF_PROG_TYPE_PHYS_DEV hook in mlx4 driver. Since
> bpf programs require a skb context to navigate the packet, build a
> percpu fake skb with the minimal fields. This avoids the costly
> allocation for packets that end
Add support for the BPF_PROG_TYPE_PHYS_DEV hook in mlx4 driver. Since
bpf programs require a skb context to navigate the packet, build a
percpu fake skb with the minimal fields. This avoids the costly
allocation for packets that end up being dropped.
Since mlx4 is so far the only user of this pse
25 matches
Mail list logo
