On Thu, Oct 11, 2012 at 1:34 PM,  <[email protected]> wrote:
> This is a mobile telecom domain. Let us say, in LTE, S1 signalling is 
> following by S11 leg signalling and following by data intermixed.
>
> If I need to filter a 10G pcap file, so that synchronization has to be 
> maintained, then S1->NIC-X frame should go and only post than S11->NIC-Y 
> should go.
>
> If I need to maintain this, then I would load same frame in both the 2 
> NICs,then if S1's filter criteria in met for NIC1, then I use the signal that 
> kernel->please process this slot, or else I should reload next frame into 
> that slot.
>
> I believe this should be possible. Please correct me if I am wrong.

Probably, in your case the biggest problem is to keep up correct
timing. You need high-performance, so sendto(2) with PF_PACKET isn't
an option, right? Probably, it would be good run a filter once on a
temporary buffer and then depending on the filter outcome, you copy it
somewhere. Also, you could determine the NIC from the filter return
code (if you write your own filter with bpfc, for instance), e.g. if
ret==0 -> drop, ret==1 -> give it to NIC0, ret==2 -> give it to NIC1
and so on.

> Regards,
> Sibir
>
>
> The issue here is that taken a frame,
>
>
> On Thursday, October 11, 2012 2:48:34 AM UTC+5:30, Daniel Borkmann wrote:
>> On Wed, Oct 10, 2012 at 6:59 PM,  <[email protected]> wrote:
>>
>> > Thanks much. I can understand the idea. But pushing at 10G at that way may 
>> > not be possible practically.
>>
>>
>>
>> Is this just an assumption or did you try what I suggested?
>>
>>
>>
>> > So, just to clarify:
>>
>> >
>>
>> > Test Case:
>>
>> > 1) 2-10G Intel Igxbe cards -82599EB based.
>>
>> > 2) The same pcap file has like: Frame 1->NIC1, Frame 2->NIC1, Frame 
>> > n->NICn (It is random). Only by examining the inner details like Port etc 
>> > like if HTTP goto NIC1 if FTP, goto NIC2, etc.
>>
>>
>>
>> You second statement contradicts itself. If you want randomly any
>>
>> frame to be pushed out by NIC1 or NIC2, then filtering might not be an
>>
>> option, since it's not random. But obviously it might be an option
>>
>> since you state it in our next sentence. How big is your pcap file?
>>
>> So, as I suggested, start two instances, one that has outgoing device
>>
>> NIC1, bound CPU0, filter for HTTP; the other one NIC2, bound CPU1 and
>>
>> a filter for FTP.
>>
>>
>>
>> > Use of Zero Copy Netsniff-ng:
>>
>> >
>>
>> > 1) Read each frame. Copy to NIC buffer using:
>>
>> >
>>
>> > So, what is this outer loop?
>>
>> >
>>
>> >                 while (user_may_pull_from_tx(tx_ring.frames[it].iov_base)) 
>> > {
>>
>> >                         struct pcap_pkthdr phdr;
>>
>> >                         hdr = tx_ring.frames[it].iov_base;
>>
>> >                         /* Kernel assumes: data = ph.raw + po->tp_hdrlen -
>>
>> >                          * sizeof(struct sockaddr_ll); */
>>
>> >                         out = ((uint8_t *) hdr) + TPACKET_HDRLEN -
>>
>> >                               sizeof(struct sockaddr_ll);
>>
>>
>>
>> Everything is said and done in the code. It looks for a free ring slot
>>
>> that we can fill (one that is not currently processed by the kernel).
>>
>> Then we set up our pointer for filling it with payload (== ``out''
>>
>> pointer).
>>
>>
>>
>> > And, what is this innerloop?
>>
>> >
>>
>> >                         do {
>>
>> >                                 memset(&phdr, 0, sizeof(phdr));
>>
>> >                                 ret = 
>> > pcap_ops[mode->pcap]->read_pcap_pkt(fd, &phdr,
>>
>> >                                                 out, 
>> > ring_frame_size(&tx_ring));
>>
>> >                                 if (unlikely(ret <= 0))
>>
>> >                                         goto out;
>>
>> >                                 if (ring_frame_size(&tx_ring) < phdr.len) {
>>
>> >                                         phdr.len = 
>> > ring_frame_size(&tx_ring);
>>
>> >                                         trunced++;
>>
>> >                                 }
>>
>> >                         } while (mode->filter && !bpf_run_filter(&bpf_ops, 
>> > out, phdr.len));
>>
>> >                         pcap_pkthdr_to_tpacket_hdr(&phdr, &hdr->tp_h);
>>
>>
>>
>> It takes the ``out'' pointer, reads the next packet from the pcap file
>>
>> into it, performs some sanity checks and runs the BPF machine on the
>>
>> content that is saved in ``out''. It it passes the filter, then we
>>
>> leave the loop, if not, we read out the next packet and so on until a
>>
>> packet passes it.
>>
>>
>>
>> > Also please, if possible, send a user mode filter (even if it is early 
>> > development stages). Even a rough code would do.
>>
>>
>>
>> Read the docs of bpfc:
>>
>>
>>
>> https://github.com/gnumaniacs/netsniff-ng/blob/master/Documentation/Bpfc
>>
>> https://github.com/gnumaniacs/netsniff-ng/tree/master/src/examples/bpfc
>>
>>
>>
>> you can then pass the outcome of ``bpfc myfilter-file'' to
>>
>> netsniff-ng's --filter option. Or if this is too much trouble, you can
>>
>> also create it with ``tcpdump -dd my-filter-string'' and pass the
>>
>> outcome to netsniff-ng. It's the same underlying mechanism.
>>
>>
>>
>> > On Monday, October 8, 2012 4:04:46 PM UTC+5:30, [email protected] 
>> > wrote:
>>
>> >> I downloaded and compiled the netsniff-ng. The replay works perfectly for 
>> >> 10G and 1G rates, well above other open source softwares. I have achieved 
>> >> around close to 2.6 Mpps with 512 byte packets and close to 5Mpps in 10G 
>> >> Intel Ixgbe card.
>>
>> >>
>>
>> >> I have a few queries:
>>
>> >>
>>
>> >> 1) In the code for netnsiff-ng, it expects bpf filter which is applied on 
>> >> the Pcap file. Can I instead apply the filter on the TxRing ie. the Intel 
>> >> NIC card? So that multiple TxRings can have multiple filters.
>>
>> >>
>>
>> >> eg. eth1#SrcPort=1233-1244
>>
>> >>       eth2#IPSrc=1.2.3.4/16 etc.
>>
>> >>
>>
>> >> 2) One more requirement is that, is it possible to get a bpf filter from 
>> >> command line in a human readable format like SrcPort like the one in 
>> >> tcpreplay ?
>>
>> >
>>
>> > --
>>
>> >
>>
>> >
>
> --
>
>

-- 


Reply via email to