modify follow af_xdp codes ,however it can't work

[lddlww]

https://github.com/atoonk/go-pktgen/blob/5ccee3f8cf0465577bb637a0d66754ec99f8c7b7/pktgen/af_xdp.go#L79C1-L95C3

        var descCh = make(chan []xdp.Desc, 10000)

        go func() {
                for {
                        select {
                        case <-ctx.Done():
                                return
                        default:
                                descs := xsk.GetDescs(xsk.NumFreeTxSlots(), false)
                                for i:=range descs{
                                        descs[i].Len=uint32(frameLen)
                                }
                                if len(descs)==0{
                                        continue
                                }
                                descCh <- descs
                        }
                }
        }()

        for {
                select {
                case <-ctx.Done():
                        return nil
                case descs := <-descCh:
                        xsk.Transmit(descs)

                        _, _, err := xsk.Poll(-1)
                        if err != nil {
                                panic(err)
                        }
                }
        }

i used a goroutine to produce descs , the other goroutine for send descs, their communicate with descCh channel, but it can't send any more udp traffic

i check github.com/asavie/xdp/xdp.go found it can't update xsk.completionRing.Producer

am i missing something else?

[atoonk]

Hi, I haven't tested your code, but this assumes that getting and filling are the bottlenecks. If your code works and you don't see any improvements, then I guess that's not a real bottleneck. I'd assume only a minor improvement...

The real limit is likely the ability for the Kernel / NIC to send the data. The only real way to work around that is more NIC Queues. That will allow you to parallelize this.

[lddlww]

The real limit is likely the ability for the Kernel / NIC to send the data. The only real way to work around that is more NIC Queues. That will allow you to parallelize this.

thanks for your suggestion， and i am closing this issue now