Re: [Intel-wired-lan] [PATCH iwl-next v1 1/5] net: docs: add missing features that can have stats

2024-06-04 Thread Rahul Rameshbabu
; > Fix up the docs to match the kernel code, and while there, sort them in > alphabetical order. > > Cc: Rahul Rameshbabu > Reviewed-by: Jacob Keller > Signed-off-by: Jesse Brandeburg > --- > I didn't add a Fixes: tag because this is not an urgent kind of fix that

Re: [Intel-wired-lan] [PATCH iwl-next v5 08/12] iavf: periodically cache PHC time

2024-04-25 Thread Rahul Rameshbabu
On Thu, 25 Apr, 2024 16:28:22 + "Keller, Jacob E" wrote: >> -Original Message- >> From: Kitszel, Przemyslaw >> Sent: Thursday, April 25, 2024 3:52 AM >> To: Keller, Jacob E ; Polchlopek, Mateusz >> ; Rahul Rameshbabu >>

Re: [Intel-wired-lan] [PATCH iwl-next v5 00/12] Add support for Rx timestamping for both ice and iavf drivers.

2024-04-22 Thread Rahul Rameshbabu
On Mon, 22 Apr, 2024 11:37:14 +0200 Mateusz Polchlopek wrote: > On 4/18/2024 10:19 PM, Rahul Rameshbabu wrote: >> On Thu, 18 Apr, 2024 01:24:48 -0400 Mateusz Polchlopek >> wrote: >>> Initially, during VF creation it registers the PTP clock in >>> the s

Re: [Intel-wired-lan] [PATCH iwl-next v5 00/12] Add support for Rx timestamping for both ice and iavf drivers.

2024-04-18 Thread Rahul Rameshbabu
ome after the Signed-off-by: trailer, since the review happens after the patches have been written. -- Thanks, Rahul Rameshbabu

Re: [Intel-wired-lan] [PATCH iwl-next v5 12/12] iavf: add support for Rx timestamps to hotpath

2024-04-18 Thread Rahul Rameshbabu
ement timestamp extension as iavf_ptp_extend_32b_timestamp(), > and extract and forward only the 32bits of nominal nanoseconds. > > Reviewed-by: Wojciech Drewek > Signed-off-by: Jacob Keller > Signed-off-by: Mateusz Polchlopek > --- Reviewed-by: Rahul Rameshbabu

Re: [Intel-wired-lan] [PATCH iwl-next v5 11/12] iavf: handle SIOCSHWTSTAMP and SIOCGHWTSTAMP

2024-04-18 Thread Rahul Rameshbabu
t; SIOCGHWTSTAMP. > > The Tx timestamps are not implemented yet so calling SIOCSHWTSTAMP for > Tx path will end with EOPNOTSUPP error code. > > Reviewed-by: Wojciech Drewek > Signed-off-by: Jacob Keller > Co-developed-by: Mateusz Polchlopek > Signed-off-by: Mateusz Polchlopek > --- Reviewed-by: Rahul Rameshbabu

Re: [Intel-wired-lan] [PATCH iwl-next v5 09/12] iavf: refactor iavf_clean_rx_irq to support legacy and flex descriptors

2024-04-18 Thread Rahul Rameshbabu
C_STATUS_ERR0_EOP_BIT, > + le16_to_cpu(status0)); > + fields->rxe = FIELD_GET(IAVF_RX_FLEX_DESC_STATUS_ERR0_RXE_BIT, > + le16_to_cpu(status0)); > +} > + > +static void iavf_extract_rx_fields(struct iavf_ring *rx_ring, > +union iavf_rx_desc *rx_desc, > +struct iavf_rx_extracted *fields) > +{ > + if (rx_ring->rxdid == VIRTCHNL_RXDID_1_32B_BASE) > + iavf_extract_legacy_rx_fields(rx_ring, rx_desc, fields); > + else > + iavf_extract_flex_rx_fields(rx_ring, rx_desc, fields); > +} > + -- Thanks, Rahul Rameshbabu

Re: [Intel-wired-lan] [PATCH iwl-next v5 10/12] iavf: Implement checking DD desc field

2024-04-18 Thread Rahul Rameshbabu
usly set struct fields are being checked. The field DD > (descriptor done) needs to be checked at the very beginning, before > extracting other fields. > > Reviewed-by: Wojciech Drewek > Signed-off-by: Mateusz Polchlopek > --- Reviewed-by: Rahul Rameshbabu

Re: [Intel-wired-lan] [PATCH iwl-next v5 08/12] iavf: periodically cache PHC time

2024-04-18 Thread Rahul Rameshbabu
On Thu, 18 Apr, 2024 01:24:56 -0400 Mateusz Polchlopek wrote: > From: Jacob Keller > > The Rx timestamps reported by hardware may only have 32 bits of storage > for nanosecond time. These timestamps cannot be directly reported to the > Linux stack, as it expects 64bits of time. > > To handle thi

Re: [Intel-wired-lan] [PATCH iwl-next v5 07/12] iavf: add support for indirect access to PHC time

2024-04-18 Thread Rahul Rameshbabu
onse from the PF is processed and stored into > the cached_phc_time. A wait queue is used to allow the PTP clock gettime > request to sleep until the message is sent from the PF. > > Reviewed-by: Wojciech Drewek > Signed-off-by: Jacob Keller > Signed-off-by: Mateusz Polchlopek > --- Reviewed-by: Rahul Rameshbabu

Re: [Intel-wired-lan] [PATCH iwl-next v5 06/12] iavf: add initial framework for registering PTP clock

2024-04-18 Thread Rahul Rameshbabu
; I think teardown should be LIFO order to initialization. I would move this line to the beginning of the function before any resources are actually released. > +} -- Thanks, Rahul Rameshbabu

Re: [Intel-wired-lan] [PATCH iwl-next v5 05/12] iavf: negotiate PTP capabilities

2024-04-18 Thread Rahul Rameshbabu
+ > + if (!PTP_ALLOWED(adapter)) > + return -EOPNOTSUPP; > + > + hw_caps.caps = (VIRTCHNL_1588_PTP_CAP_READ_PHC | > + VIRTCHNL_1588_PTP_CAP_RX_TSTAMP); > + > + adapter->current_op = VIRTCHNL_OP_1588_PTP_GET_CAPS; > + > + return iavf_send_pf_msg(adapter, VIRTCHNL_OP_1588_PTP_GET_CAPS, > + (u8 *)&hw_caps, sizeof(hw_caps)); > +} > + > /** > * iavf_validate_num_queues > * @adapter: adapter structure -- Thanks, Rahul Rameshbabu

Re: [Intel-wired-lan] [PATCH iwl-next v5 04/12] iavf: add support for negotiating flexible RXDID format

2024-04-18 Thread Rahul Rameshbabu
t; + * do not expect a response. > + */ > + adapter->extended_caps &= ~IAVF_EXTENDED_CAP_RECV_RXDID; > + } > + > + /* We sent the message, so move on to the next step */ > + adapter->extended_caps &= ~IAVF_EXTENDED_CAP_SEND_RXDID; > +} > + -- Thanks, Rahul Rameshbabu

Re: [Intel-wired-lan] [PATCH iwl-next v5 03/12] virtchnl: add enumeration for the rxdid format

2024-04-18 Thread Rahul Rameshbabu
gt; > Reviewed-by: Wojciech Drewek > Signed-off-by: Jacob Keller > Signed-off-by: Mateusz Polchlopek > --- Reviewed-by: Rahul Rameshbabu

Re: [Intel-wired-lan] [PATCH iwl-next v5 02/12] ice: support Rx timestamp on flex descriptor

2024-04-18 Thread Rahul Rameshbabu
rxdid, 0x03, true); > + else > + ice_write_qrxflxp_cntxt(&vsi->back->hw, > + vsi->rxq_map[q_idx], > + rxdid, 0x03, false); > } > } > -- Thanks, Rahul Rameshbabu

Re: [Intel-wired-lan] [PATCH iwl-next v5 01/12] virtchnl: add support for enabling PTP on iAVF

2024-04-18 Thread Rahul Rameshbabu
ture is > specifically set aside for this. > Additionally, each structure has some space reserved for future > extensions to allow some flexibility. > > Reviewed-by: Wojciech Drewek > Signed-off-by: Jacob Keller > Signed-off-by: Mateusz Polchlopek > --- Reviewed-by: Rahul Rameshbabu