Jason Xing wrote:
> On Tue, Jul 22, 2025 at 10:16 PM Willem de Bruijn
> wrote:
> >
> > Jason Xing wrote:
> > > Hi Paul,
> > >
> > > On Mon, Jul 21, 2025 at 4:56 PM Paul Menzel wrote:
> > > >
> > > > Dear Jason,
> > >
Jason Xing wrote:
> Hi Paul,
>
> On Mon, Jul 21, 2025 at 4:56 PM Paul Menzel wrote:
> >
> > Dear Jason,
> >
> >
> > Thank you for your patch.
>
> Thanks for your quick response and review :)
>
> >
> > Am 21.07.25 um 10:33 schrieb Jason Xing:
> > > From: Jason Xing
> > >
> > > The issue can hap
w fields to struct idpf_vport_user_config_data to save the user
> settings and re-apply them after reset.
>
> Reviewed-by: Madhu Chittim
> Signed-off-by: Ahmed Zaki
Reviewed-by: Willem de Bruijn
both ARM and x86 archs.
>
> Signed-off-by: Milena Olech
> Reviewed-by: Karol Kolacinski
Reviewed-by: Willem de Bruijn
Olech, Milena wrote:
> On 01/10/2025 10:34PM Willem de Bruijn wrote:
>
> > > > > Add functions to request Tx timestamp for the PTP packets, read the Tx
> > > > > timestamp when the completion tag for that packet is being received,
> > > > >
Olech, Milena wrote:
> On 01/07/2025 3:55PM Willem de Bruijn wrote:
>
> > > Add functions to request Tx timestamp for the PTP packets, read the Tx
> > > timestamp when the completion tag for that packet is being received,
> > > extend the Tx timestamp value a
Milena Olech wrote:
> Add functions to request Tx timestamp for the PTP packets, read the Tx
> timestamp when the completion tag for that packet is being received,
> extend the Tx timestamp value and set the supported timestamping modes.
>
> Tx timestamp is requested for the PTP packets by setting
t the Tx timestamp capabilities and parse the uplink
> vport flag.
>
> Reviewed-by: Alexander Lobakin
> Co-developed-by: Emil Tantilov
> Signed-off-by: Emil Tantilov
> Co-developed-by: Pavan Kumar Linga
> Signed-off-by: Pavan Kumar Linga
> Signed-off-by: Milena Olech
Reviewed-by: Willem de Bruijn
ned-off-by: Milena Olech
Reviewed-by: Willem de Bruijn
Milena Olech wrote:
> Add Rx timestamp function when the Rx timestamp value is read directly
> from the Rx descriptor. In order to extend the Rx timestamp value to 64
> bit in hot path, the PHC time is cached in the receive groups.
> Add supported Rx timestamp modes.
>
> Reviewed-by: Alexander Lob
Milena Olech wrote:
> Add functions to request Tx timestamp for the PTP packets, read the Tx
> timestamp when the completion tag for that packet is being received,
> extend the Tx timestamp value and set the supported timestamping modes.
>
> Tx timestamp is requested for the PTP packets by setting
Milena Olech wrote:
> Tx timestamp capabilities are negotiated for the uplink Vport.
> Driver receives information about the number of available Tx timestamp
> latches, the size of Tx timestamp value and the set of indexes used
> for Tx timestamping.
>
> Add function to get the Tx timestamp capabi
to the stack.
>
> Reviewed-by: Alexander Lobakin
> Tested-by: Willem de Bruijn
> Signed-off-by: Milena Olech
Reviewed-by: Willem de Bruijn
> ---
> v1 -> v2: change the size of access fields in ptp struct
also removes dependency on CONFIG_PCIE_PTM
Olech, Milena wrote:
> On 11/14/2024 9:54 PM, Willem de Bruijn wrote:
>
> > Milena Olech wrote:
> > > Add Rx timestamp function when the Rx timestamp value is read directly
> > > from the Rx descriptor. Add supported Rx timestamp modes.
> > >
> > &
Olech, Milena wrote:
> On 11/15/2024 12:20 AM, Willem de Bruijn wrote:
>
> > Milena Olech wrote:
> > > Add functions to request Tx timestamp for the PTP packets, read the Tx
> > > timestamp when the completion tag for that packet is being received,
> > > ex
Olech, Milena wrote:
> On 11/14/2024 9:20 PM, Willem de Bruijn wrote:
>
> > Milena Olech wrote:
> > > PTP capabilities are negotiated using virtchnl command. Add get
> > > capabilities function, direct access to read the PTP clock time and
> > > direct acce
to the stack.
>
> Reviewed-by: Alexander Lobakin
> Signed-off-by: Milena Olech
Tested-by: Willem de Bruijn
- Brought up a device
- Verified the virtchannel capability negotiation
- Verified /dev/ptp0 becomes availabe
- Read the device clock using clock_gettime(FD_TO_CLOCKID(fd), &ts)
- Verifi
Milena Olech wrote:
> Add functions to request Tx timestamp for the PTP packets, read the Tx
> timestamp when the completion tag for that packet is being received,
> extend the Tx timestamp value and set the supported timestamping modes.
>
> Tx timestamp is requested for the PTP packets by setting
Vadim Fedorenko wrote:
> > +/**
> > + * idpf_ptp_read_src_clk_reg_direct - Read directly the main timer value
> > + * @adapter: Driver specific private structure
> > + * @sts: Optional parameter for holding a pair of system timestamps from
> > + * the system clock. Will be ignored when NULL is gi
Milena Olech wrote:
> Add Rx timestamp function when the Rx timestamp value is read directly
> from the Rx descriptor. Add supported Rx timestamp modes.
>
> Reviewed-by: Alexander Lobakin
> Signed-off-by: Milena Olech
> ---
> drivers/net/ethernet/intel/idpf/idpf_ptp.c | 74
Milena Olech wrote:
> Tx timestamp capabilities are negotiated for the uplink Vport.
> Driver receives information about the number of available Tx timestamp
> latches, the size of Tx timestamp value and the set of indexes used
> for Tx timestamping.
>
> Add function to get the Tx timestamp capabi
and add functions to enable these actions using dedicated virtchnl
> messages.
>
> Reviewed-by: Alexander Lobakin
> Signed-off-by: Milena Olech
Reviewed-by: Willem de Bruijn
negotiation.
>
> Add functions to recognize PTP messages, move them to dedicated secondary
> mailbox, read the PTP clock time and cross timestamp using mailbox
> messages.
>
> Reviewed-by: Alexander Lobakin
> Signed-off-by: Milena Olech
Reviewed-by: Willem de Bruijn
to the stack.
>
> Reviewed-by: Alexander Lobakin
> Signed-off-by: Milena Olech
Tested-by: Willem de Bruijn
> /**
> * struct idpf_ptp - PTP parameters
> * @info: structure defining PTP hardware capabilities
> * @clock: pointer to registered PTP clock device
> * @adapter: ba
Milena Olech wrote:
> Move virtchnl strucutres to the header file to expose them for the PTP
> virtchnl file.
Minor: s/strucutres/structures
> Reviewed-by: Alexander Lobakin
> Signed-off-by: Milena Olech
Reviewed-by: Willem de Bruijn
- maximum
> adjustment of the clock and the basic increment value.
>
> Additionally, API allows to configure the secondary mailbox, dedicated
> exclusively for PTP purposes.
>
> Reviewed-by: Alexander Lobakin
> Signed-off-by: Milena Olech
minor issue, with that addressed
R
Milena Olech wrote:
> PTP feature is supported if the VIRTCHNL2_CAP_PTP is negotiated during the
> capabilities recognition. Initial PTP support includes PTP initialization
> and registration of the clock.
>
> Reviewed-by: Alexander Lobakin
> Signed-off-by: Milena Olech
Revi
Krzysztof Galazka wrote:
> For IPv4 and IPv6 packets shorter than minimum Ethernet
> frame payload, recvmsg returns lenght including padding.
nit: length
> Use length from header for checksum verification to avoid
> csum test failing on correct packets.
>
> Fixes: 1d0dc857b5d8 (selftests: drv-ne
Manoj Vishwanathan wrote:
> From: Willem de Bruijn
>
> The virtchannel control queue is lossy to avoid deadlock. Ensure that
> no losses occur in practice. Detect a full queue, when overflows may
> have happened.
>
> In practice, virtchnl is synchronous currenty and messag
Alexander Lobakin wrote:
> From: Willem De Bruijn
> Date: Mon, 17 Jun 2024 14:13:07 -0400
>
> > Alexander Lobakin wrote:
> >> From: Willem De Bruijn
> >> Date: Thu, 30 May 2024 09:46:46 -0400
> >>
> >>> Alexander Lobakin wrote:
> >
Alexander Lobakin wrote:
> From: Willem De Bruijn
> Date: Thu, 30 May 2024 09:46:46 -0400
>
> > Alexander Lobakin wrote:
> >> Currently, idpf uses the following model for the header buffers:
> >>
> >> * buffers are allocated via dma_alloc_coherent();
Alexander Lobakin wrote:
> Currently, idpf uses the following model for the header buffers:
>
> * buffers are allocated via dma_alloc_coherent();
> * when receiving, napi_alloc_skb() is called and then the header is
> copied to the newly allocated linear part.
>
> This is far from optimal as DM
Alan Brady wrote:
> This takes care of RSS/SRIOV/MAC and other misc virtchnl messages. This
> again is mostly mechanical. There's some added functionality with MAC
> filters which makes sure we remove bad filters now that we can better
> handle asynchronous messages.
Can you split the part that is
Alan Brady wrote:
> The motivation for this series has two primary goals. We want to enable
> support of multiple simultaneous messages and make the channel more
> robust. The way it works right now, the driver can only send and receive
> a single message at a time and if something goes really wron
Alexander Lobakin wrote:
> From: Willem De Bruijn
> Date: Wed, 27 Dec 2023 10:30:48 -0500
>
> > Alexander Lobakin wrote:
> >> Currently, idpf uses the following model for the header buffers:
> >>
> >> * buffers are allocated via dma_alloc_coherent();
Alexander Lobakin wrote:
> From: Willem De Bruijn
> Date: Tue, 26 Dec 2023 15:23:41 -0500
>
> > Alexander Lobakin wrote:
> >> I was highly asked to send this WIP before the holidays to trigger
> >> some discussions at least for the generic parts.
> >>
&
Alexander Lobakin wrote:
> idpf's in-kernel parsed ptype structure is almost identical to the one
> used in the previous Intel drivers, which means it can be converted to
> use libie's definitions and even helpers. The only difference is that
> it doesn't use a constant table, rather than one obtai
Alexander Lobakin wrote:
> Currently, idpf uses the following model for the header buffers:
>
> * buffers are allocated via dma_alloc_coherent();
> * when receiving, napi_alloc_skb() is called and then the header is
> copied to the newly allocated linear part.
>
> This is far from optimal as DM
Alexander Lobakin wrote:
> I was highly asked to send this WIP before the holidays to trigger
> some discussions at least for the generic parts.
>
> This all depends on libie[0] and WB-on-ITR fix[1]. The RFC does not
> guarantee to work perfectly, but at least regular XDP seems to work
> for me...
On Tue, Oct 10, 2023 at 5:34 PM Ahmed Zaki wrote:
>
>
> On 2023-10-10 14:40, Willem de Bruijn wrote:
>
> On Tue, Oct 10, 2023 at 4:05 PM Ahmed Zaki wrote:
>
> Symmetric RSS hash functions are beneficial in applications that monitor
> both Tx and Rx packets of the
On Tue, Oct 10, 2023 at 4:05 PM Ahmed Zaki wrote:
>
> Symmetric RSS hash functions are beneficial in applications that monitor
> both Tx and Rx packets of the same flow (IDS, software firewalls, ..etc).
> Getting all traffic of the same flow on the same RX queue results in
> higher CPU cache effic
On Fri, Oct 6, 2023 at 7:22 PM Jakub Kicinski wrote:
>
> On Fri, 6 Oct 2023 16:47:21 -0600 Ahmed Zaki wrote:
> > Symmetric RSS hash functions are beneficial in applications that monitor
> > both Tx and Rx packets of the same flow (IDS, software firewalls, ..etc).
> > Getting all traffic of the sa
42 matches
Mail list logo
