On Tue, Dec 04, 2018 at 10:29:04AM +0100, Jesper Dangaard Brouer wrote:
> On Mon, 3 Dec 2018 23:24:18 -0800
> Jakub Kicinski wrote:
>
> > On Tue, 04 Dec 2018 09:03:52 +0200, Toke Høiland-Jørgensen wrote:
> > > David Miller writes:
> > >
> > > > From: David Ahern
> > > > Date: Mon, 3 Dec 2018
On Tue, 4 Dec 2018 10:29:04 +0100, Jesper Dangaard Brouer wrote:
> On Mon, 3 Dec 2018 23:24:18 -0800
> Jakub Kicinski wrote:
>
> > On Tue, 04 Dec 2018 09:03:52 +0200, Toke Høiland-Jørgensen wrote:
> > > David Miller writes:
> > >
> > > > From: David Ahern
> > > > Date: Mon, 3 Dec 2018 17
On Mon, 3 Dec 2018 23:24:18 -0800
Jakub Kicinski wrote:
> On Tue, 04 Dec 2018 09:03:52 +0200, Toke Høiland-Jørgensen wrote:
> > David Miller writes:
> >
> > > From: David Ahern
> > > Date: Mon, 3 Dec 2018 17:15:03 -0700
> > >
> > >> So, instead of a program tag which the program writer c
On Tue, 04 Dec 2018 09:03:52 +0200, Toke Høiland-Jørgensen wrote:
> David Miller writes:
>
> > From: David Ahern
> > Date: Mon, 3 Dec 2018 17:15:03 -0700
> >
> >> So, instead of a program tag which the program writer controls, how
> >> about some config knob that an admin controls that says at
David Miller writes:
> From: David Ahern
> Date: Mon, 3 Dec 2018 17:15:03 -0700
>
>> So, instead of a program tag which the program writer controls, how
>> about some config knob that an admin controls that says at attach time
>> use standard stats?
>
> How about, instead of replacing it is in a
From: David Ahern
Date: Mon, 3 Dec 2018 17:15:03 -0700
> So, instead of a program tag which the program writer controls, how
> about some config knob that an admin controls that says at attach time
> use standard stats?
How about, instead of replacing it is in addition to, and admin can
override
On 12/3/18 5:00 PM, David Miller wrote:
> From: Toke Høiland-Jørgensen
> Date: Mon, 03 Dec 2018 22:00:32 +0200
>
>> I wonder if it would be possible to support both the "give me user
>> normal stats" case and the "let me do whatever I want" case by a
>> combination of userspace tooling and maybe
From: Toke Høiland-Jørgensen
Date: Mon, 03 Dec 2018 22:00:32 +0200
> I wonder if it would be possible to support both the "give me user
> normal stats" case and the "let me do whatever I want" case by a
> combination of userspace tooling and maybe a helper or two?
>
> I.e., create a "do_stats()"
David Miller writes:
> From: David Ahern
> Date: Mon, 3 Dec 2018 08:45:12 -0700
>
>> On 12/1/18 4:22 AM, Jesper Dangaard Brouer wrote:
>>> IMHO XDP_DROP should not be accounted as netdev stats drops, this is
>>> a user installed program like tc/iptables, that can also choose to
>>> drop packets.
Em Mon, Dec 03, 2018 at 11:30:01AM -0800, David Miller escreveu:
> From: David Ahern
> Date: Mon, 3 Dec 2018 08:45:12 -0700
>
> > On 12/1/18 4:22 AM, Jesper Dangaard Brouer wrote:
> >> IMHO XDP_DROP should not be accounted as netdev stats drops, this is a
> >> user installed program like tc/iptab
From: David Ahern
Date: Mon, 3 Dec 2018 08:56:28 -0700
> I do not want Linux + XDP to require custom anything to debug basic
> functionality - such as isolating a packet drop to a specific point.
Definitely we need to let people choose to arrange things that way
if they want to do so. It is not
From: David Ahern
Date: Mon, 3 Dec 2018 08:45:12 -0700
> On 12/1/18 4:22 AM, Jesper Dangaard Brouer wrote:
>> IMHO XDP_DROP should not be accounted as netdev stats drops, this is a
>> user installed program like tc/iptables, that can also choose to drop
>> packets.
>
> sure and both tc and iptab
On 12/1/18 4:14 AM, Jesper Dangaard Brouer wrote:
>>> XDP dropping a packet is completely different.
>>>
>>> stats are important. packets disappearing with no counters -- standard
>>> counters visible by standard tools -- is a user nightmare. If the
>>> agreement is for XDP drops to be in driver le
On 12/1/18 4:22 AM, Jesper Dangaard Brouer wrote:
>>
>> So we should count all XDP RX packets as successful rx packets i.e
>> netdev->stats.rx_packets++; regardless of the XDP program decision ?
>
> Yes.
>
>> this implies that XDP_TX packets will be counted twice once in
>> netdev->stats.rx_pac
On Fri, 30 Nov 2018 23:54:10 +
Saeed Mahameed wrote:
> On Fri, 2018-11-30 at 15:30 -0500, Michael S. Tsirkin wrote:
> > On Fri, Nov 30, 2018 at 08:10:58PM +, Saeed Mahameed wrote:
> > > On Thu, 2018-11-22 at 18:00 +0100, Toke Høiland-Jørgensen wrote:
> > > > David Ahern writes:
> > >
On Fri, 30 Nov 2018 20:41:48 -0800
Jakub Kicinski wrote:
> On Fri, 30 Nov 2018 13:35:53 -0700, David Ahern wrote:
> > On 11/30/18 1:30 PM, Michael S. Tsirkin wrote:
> > I would like to see basic packets, bytes, and dropped counters
> > tracked
> > for Rx and Tx via the standard n
On Fri, 30 Nov 2018 13:35:53 -0700, David Ahern wrote:
> On 11/30/18 1:30 PM, Michael S. Tsirkin wrote:
> I would like to see basic packets, bytes, and dropped counters
> tracked
> for Rx and Tx via the standard netdev counters for all devices.
> >>
> >> The problem of reporting X
On Fri, 2018-11-30 at 15:30 -0500, Michael S. Tsirkin wrote:
> On Fri, Nov 30, 2018 at 08:10:58PM +, Saeed Mahameed wrote:
> > On Thu, 2018-11-22 at 18:00 +0100, Toke Høiland-Jørgensen wrote:
> > > David Ahern writes:
> > >
> > > > On 11/22/18 1:26 AM, Toke Høiland-Jørgensen wrote:
> > > > >
On 11/30/18 1:30 PM, Michael S. Tsirkin wrote:
I would like to see basic packets, bytes, and dropped counters
tracked
for Rx and Tx via the standard netdev counters for all devices.
>>
>> The problem of reporting XDP_DROP in the netedev drop counter is that
>> they don't fit this co
On Fri, Nov 30, 2018 at 08:10:58PM +, Saeed Mahameed wrote:
> On Thu, 2018-11-22 at 18:00 +0100, Toke Høiland-Jørgensen wrote:
> > David Ahern writes:
> >
> > > On 11/22/18 1:26 AM, Toke Høiland-Jørgensen wrote:
> > > > Saeed Mahameed writes:
> > > >
> > > > > > > I'd say it sounds reasonab
On Thu, 2018-11-22 at 18:00 +0100, Toke Høiland-Jørgensen wrote:
> David Ahern writes:
>
> > On 11/22/18 1:26 AM, Toke Høiland-Jørgensen wrote:
> > > Saeed Mahameed writes:
> > >
> > > > > > I'd say it sounds reasonable to include XDP in the normal
> > > > > > traffic
> > > > > > counters, but
On 2018/11/28 13:03, Jason Wang wrote:
> On 2018/11/27 下午3:04, Toshiaki Makita wrote:
>> On 2018/11/26 10:37, Toshiaki Makita wrote:
>>> On 2018/11/23 1:43, David Ahern wrote:
On 11/21/18 5:53 PM, Toshiaki Makita wrote:
>> We really need consistency in the counters and at a minimum, users
On 2018/11/27 下午3:04, Toshiaki Makita wrote:
On 2018/11/26 10:37, Toshiaki Makita wrote:
On 2018/11/23 1:43, David Ahern wrote:
On 11/21/18 5:53 PM, Toshiaki Makita wrote:
We really need consistency in the counters and at a minimum, users
should be able to track packet and byte counters for
On 2018/11/26 10:37, Toshiaki Makita wrote:
> On 2018/11/23 1:43, David Ahern wrote:
>> On 11/21/18 5:53 PM, Toshiaki Makita wrote:
We really need consistency in the counters and at a minimum, users
should be able to track packet and byte counters for both Rx and Tx
including XDP.
>>
On Wed, 21 Nov 2018 14:06:49 -0700, David Ahern wrote:
> Keeping the basic xdp packets in the standard counters allows Paweł, for
> example, to continue to monitor /proc/net/dev.
>
> Can we get agreement on this? And from there, get updates to the mlx5
> and virtio drivers?
I have a long standing
On 2018/11/23 1:43, David Ahern wrote:
> On 11/21/18 5:53 PM, Toshiaki Makita wrote:
>>> We really need consistency in the counters and at a minimum, users
>>> should be able to track packet and byte counters for both Rx and Tx
>>> including XDP.
>>>
>>> It seems to me the Rx and Tx packet, byte an
From: David Ahern
Date: Thu, 22 Nov 2018 09:51:27 -0700
> I would like to see basic packets, bytes, and dropped counters tracked
> for Rx and Tx via the standard netdev counters for all devices. This is
> for ease in accounting as well as speed and simplicity for bumping
> counters for virtual de
David Ahern writes:
> On 11/22/18 1:26 AM, Toke Høiland-Jørgensen wrote:
>> Saeed Mahameed writes:
>>
> I'd say it sounds reasonable to include XDP in the normal traffic
> counters, but having the detailed XDP-specific counters is quite
> useful
> as well... So can't we do both
On 11/22/18 1:26 AM, Toke Høiland-Jørgensen wrote:
> Saeed Mahameed writes:
>
I'd say it sounds reasonable to include XDP in the normal traffic
counters, but having the detailed XDP-specific counters is quite
useful
as well... So can't we do both (for all drivers)?
>>
>>
On 11/21/18 5:53 PM, Toshiaki Makita wrote:
>> We really need consistency in the counters and at a minimum, users
>> should be able to track packet and byte counters for both Rx and Tx
>> including XDP.
>>
>> It seems to me the Rx and Tx packet, byte and dropped counters returned
>> for the standar
Saeed Mahameed writes:
>> > I'd say it sounds reasonable to include XDP in the normal traffic
>> > counters, but having the detailed XDP-specific counters is quite
>> > useful
>> > as well... So can't we do both (for all drivers)?
>> >
>
> What are you thinking ?
> reporting XDP_DROP in interfa
On 2018/11/22 6:06, David Ahern wrote:
> Paweł ran some more XDP tests yesterday and from it found a couple of
> issues. One is a panic in the mlx5 driver unloading the bpf program
> (mlx5e_xdp_xmit); he will send a send a separate email for that problem.
>
> The problem I wanted to discuss here i
On Wed, 2018-11-21 at 22:29 +0100, Paweł Staszewski wrote:
> W dniu 21.11.2018 o 22:14, Toke Høiland-Jørgensen pisze:
> > David Ahern writes:
> >
> > > Paweł ran some more XDP tests yesterday and from it found a
> > > couple of
> > > issues. One is a panic in the mlx5 driver unloading the bpf
> >
W dniu 21.11.2018 o 22:14, Toke Høiland-Jørgensen pisze:
David Ahern writes:
Paweł ran some more XDP tests yesterday and from it found a couple of
issues. One is a panic in the mlx5 driver unloading the bpf program
(mlx5e_xdp_xmit); he will send a send a separate email for that
problem.
Sam
David Ahern writes:
> Paweł ran some more XDP tests yesterday and from it found a couple of
> issues. One is a panic in the mlx5 driver unloading the bpf program
> (mlx5e_xdp_xmit); he will send a send a separate email for that
> problem.
Same as this one, I guess?
https://marc.info/?l=linux-ne
Paweł ran some more XDP tests yesterday and from it found a couple of
issues. One is a panic in the mlx5 driver unloading the bpf program
(mlx5e_xdp_xmit); he will send a send a separate email for that problem.
The problem I wanted to discuss here is statistics for XDP context. The
short of it is
36 matches
Mail list logo
