From: Meghana Malladi <m-malladi@ti.com>
To: Paolo Abeni <pabeni@redhat.com>, <horms@kernel.org>,
<namcao@linutronix.de>, <vadim.fedorenko@linux.dev>,
<jacob.e.keller@intel.com>, <christian.koenig@amd.com>,
<sumit.semwal@linaro.org>, <sdf@fomichev.me>,
<john.fastabend@gmail.com>, <hawk@kernel.org>,
<daniel@iogearbox.net>, <ast@kernel.org>, <kuba@kernel.org>,
<edumazet@google.com>, <davem@davemloft.net>,
<andrew+netdev@lunn.ch>
Cc: <linaro-mm-sig@lists.linaro.org>,
<dri-devel@lists.freedesktop.org>, <linux-media@vger.kernel.org>,
<bpf@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<netdev@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>,
<srk@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>,
Roger Quadros <rogerq@kernel.org>, <danishanwar@ti.com>
Subject: Re: [EXTERNAL] Re: [PATCH net-next v4 2/6] net: ti: icssg-prueth: Add XSK pool helpers
Date: Tue, 4 Nov 2025 14:23:24 +0530 [thread overview]
Message-ID: <c792f4da-3385-4c14-a625-e31b09675c32@ti.com> (raw)
In-Reply-To: <ba1b48dc-b544-4c4b-be8a-d39b104cda21@ti.com>
Hi Paolo,
On 10/30/25 10:13, Meghana Malladi wrote:
> Hi Paolo,
>
> On 10/28/25 16:27, Paolo Abeni wrote:
>> On 10/23/25 11: 39 AM, Meghana Malladi wrote: > @@ -1200,6 +1218,109
>> @@ static int emac_xdp_setup(struct prueth_emac *emac, struct
>> netdev_bpf *bpf) > return 0; > } > > +static int
>> prueth_xsk_pool_enable(struct prueth_emac *emac,
>> ZjQcmQRYFpfptBannerStart
>> This message was sent from outside of Texas Instruments.
>> Do not click links or open attachments unless you recognize the source
>> of this email and know the content is safe.
>> Report Suspicious
>> <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!
>> updqHb0lvOd6ACXFPDODXzFjW2RtkIpblpWr3zui2O2JqWTyRCLKc2i7Pa7uSMBZYpq8H7tTr-jp_nDelg_OUrmNCgZ8_m0$>
>> ZjQcmQRYFpfptBannerEnd
>>
>> On 10/23/25 11:39 AM, Meghana Malladi wrote:
>>> @@ -1200,6 +1218,109 @@ static int emac_xdp_setup(struct prueth_emac
>>> *emac, struct netdev_bpf *bpf)
>>> return 0;
>>> }
>>>
>>> +static int prueth_xsk_pool_enable(struct prueth_emac *emac,
>>> + struct xsk_buff_pool *pool, u16 queue_id)
>>> +{
>>> + struct prueth_rx_chn *rx_chn = &emac->rx_chns;
>>> + u32 frame_size;
>>> + int ret;
>>> +
>>> + if (queue_id >= PRUETH_MAX_RX_FLOWS ||
>>> + queue_id >= emac->tx_ch_num) {
>>> + netdev_err(emac->ndev, "Invalid XSK queue ID %d\n", queue_id);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + frame_size = xsk_pool_get_rx_frame_size(pool);
>>> + if (frame_size < PRUETH_MAX_PKT_SIZE)
>>> + return -EOPNOTSUPP;
>>> +
>>> + ret = xsk_pool_dma_map(pool, rx_chn->dma_dev, PRUETH_RX_DMA_ATTR);
>>> + if (ret) {
>>> + netdev_err(emac->ndev, "Failed to map XSK pool: %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + if (netif_running(emac->ndev)) {
>>> + /* stop packets from wire for graceful teardown */
>>> + ret = icssg_set_port_state(emac, ICSSG_EMAC_PORT_DISABLE);
>>> + if (ret)
>>> + return ret;
>>> + prueth_destroy_rxq(emac);
>>> + }
>>> +
>>> + emac->xsk_qid = queue_id;
>>> + prueth_set_xsk_pool(emac, queue_id);
>>> +
>>> + if (netif_running(emac->ndev)) {
>>> + ret = prueth_create_rxq(emac);
>>
>> It looks like this falls short of Jakub's request on v2:
>>
>> https://urldefense.com/v3/__https://lore.kernel.org/
>> netdev/20250903174847.5d8d1c9f@kernel.org/__;!!G3vK!
>> TxEOF2PZA-2oagU7Gmq2PdyHrceI_sWFRSCMP2meOxVrs8eqStDUSTPi2kyzjva1rgUzQUtYbd9g$ <https://urldefense.com/v3/__https://lore.kernel.org/netdev/20250903174847.5d8d1c9f@kernel.org/__;!!G3vK!TxEOF2PZA-2oagU7Gmq2PdyHrceI_sWFRSCMP2meOxVrs8eqStDUSTPi2kyzjva1rgUzQUtYbd9g$>
>>
>> about not freeing the rx queue for reconfig.
>>
>
> I tried honoring Jakub's comment to avoid freeing the rx memory wherever
> necessary.
>
> "In case of icssg driver, freeing the rx memory is necessary as the
> rx descriptor memory is owned by the cppi dma controller and can be
> mapped to a single memory model (pages/xdp buffers) at a given time.
> In order to remap it, the memory needs to be freed and reallocated."
>
Just to make sure we are on the same page, does the above explanation
make sense to you or do you want me to make any changes in this series
for v5 ?
>> I think you should:
>> - stop the H/W from processing incoming packets,
>> - spool all the pending packets
>> - attach/detach the xsk_pool
>> - refill the ring
>> - re-enable the H/W
>>
>
> Current implementation follows the same sequence:
> 1. Does a channel teardown -> stop incoming traffic
> 2. free the rx descriptors from free queue and completion queue -> spool
> all pending packets/descriptors
> 3. attach/detach the xsk pool
> 4. allocate rx descriptors and fill the freeq after mapping them to the
> correct memory buffers -> refill the ring
> 5. restart the NAPI - re-enable the H/W to recv the traffic
>
> I am still working on skipping 2 and 4 steps but this will be a long
> shot. Need to make sure all corner cases are getting covered. If this
> approach looks doable without causing any regressions I might post it as
> a followup patch later in the future.
>
>> /P
>>
>
thanks,
Meghana
next prev parent reply other threads:[~2025-11-04 8:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 9:39 [PATCH net-next v4 0/6] Add AF_XDP zero copy support Meghana Malladi
2025-10-23 9:39 ` [PATCH net-next v4 1/6] net: ti: icssg-prueth: Add functions to create and destroy Rx/Tx queues Meghana Malladi
2025-10-23 9:39 ` [PATCH net-next v4 2/6] net: ti: icssg-prueth: Add XSK pool helpers Meghana Malladi
2025-10-28 10:57 ` Paolo Abeni
2025-10-30 4:43 ` [EXTERNAL] " Meghana Malladi
2025-11-04 8:53 ` Meghana Malladi [this message]
2025-11-04 23:48 ` Jakub Kicinski
2025-11-05 6:42 ` Meghana Malladi
2025-10-23 9:39 ` [PATCH net-next v4 3/6] net: ti: icssg-prueth: Add AF_XDP zero copy for TX Meghana Malladi
2025-10-23 9:39 ` [PATCH net-next v4 4/6] net: ti: icssg-prueth: Make emac_run_xdp function independent of page Meghana Malladi
2025-10-23 9:39 ` [PATCH net-next v4 5/6] net: ti: icssg-prueth: Add AF_XDP zero copy for RX Meghana Malladi
2025-10-23 9:39 ` [PATCH net-next v4 6/6] net: ti: icssg-prueth: Enable zero copy in XDP features Meghana Malladi
2025-10-24 0:56 ` [PATCH net-next v4 0/6] Add AF_XDP zero copy support Jacob Keller
2025-10-24 8:43 ` Malladi, Meghana
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c792f4da-3385-4c14-a625-e31b09675c32@ti.com \
--to=m-malladi@ti.com \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=christian.koenig@amd.com \
--cc=daniel@iogearbox.net \
--cc=danishanwar@ti.com \
--cc=davem@davemloft.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=jacob.e.keller@intel.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=namcao@linutronix.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rogerq@kernel.org \
--cc=sdf@fomichev.me \
--cc=srk@ti.com \
--cc=sumit.semwal@linaro.org \
--cc=vadim.fedorenko@linux.dev \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox